Aspect ratio works only when when width is changed not for height

All works fine for width changes.
Could you extend the property to handle as well when the height is changed to adjust width - keeping the aspect ratio.

Hi @slash851! I am not sure I'll modify this plugin, but we can create a new plugin fairly easily that will work for defining an aspect ratio to determine the width, based on the rendered height of an element:

Width-based

Height-based

And the result:

This demo makes use of the computed-variables which is a lot more flexible than these CSSplus plugins.
There are a couple more demos for defining aspect ratios, these both work with widths, but based on the code above it should be easy to see how translate a width-based solution to a height-based one:

https://codepen.io/tomhodgins/pen/oaKjQY using the syntax: --aspect-ratio: 1.777;
https://codepen.io/tomhodgins/pen/GzZGXg using the syntax: --aspect-ratio: {"width": 16, "height": 9};

and the demo above we've used --aspect-ratio: ["height", 16, 9] so we can pass in the direction, width and height separately - but you also have flexibility to structure this however suits you - here are some other ideas:

--aspect-ratio: {"height": {"width": 16, "height": 9}};
--aspect-ratio: [16, 9];

The only thing to keep in mind when exploring these solutions with height instead of width, is that layout in the browser is width-based, so the height usually ends up fitting the content. If you want to set a width based on the height you may find yourself having to give elements a min-height or max-height to help give them a size from which the width can be calculated!
Good luck and let me know if you have any questions using these solutions :D


Getting an error after worker inactivity

Happens when running the sdk-node worker.
[Error: Poll response from server was malformed: PollWorkflowTaskQueueResponse { task_token: [], workflow_execution: None, workflow_type: None, previous_started_event_id: 0, started_event_id: 0, attempt: 0, backlog_count_hint: 0, history: None, next_page_token: [], query: None, workflow_execution_task_queue: None, scheduled_time: None, started_time: None, queries: {} }]

Note for myself: This happens when the long poll times out and gets an empty response. We just need to ignore it and retry.

This was fixed back in #78


Add Spellbook Widget Mappings for ALL Spellbooks.

This PR adds mapping to all widgets in all spellbooks (Standard, Ancient, Lunar, and Arceuus).

Screenshots of mapped widgets in the widget inspector

Standard Spellbook

Ancient Spellbook

Lunar Spellbook

Arceuus Spellbook

Not to be implemented until the mapped widgets serve a purpose. Currently this only maps in the widget inspector. Closing.


Lung cancer data

Hi,
It it a good idea to use scArches (https://github.com/theislab/scarches/blob/hlca_tutorial_improvements/notebooks/hlca_map_classify.ipynb) to map the HLCA data to lung cancer data? The cancer cells are probably quite different from the healthy epithelial cells. Could this analysis reveal something interesting about the query (cancer) data? Or was this scArches application mostly designed for healthy lung scRNA-seq data?

Hi @SirKuikka , as you can read in the paper we mapped lots of disease data to the healthy HLCA core, so it should work. The quality of the mapping mostly depends on how different your data is in terms of technologies used etc. compared to the HLCA core (which is single cell 10X), for example single nucleus might not give as nice a mapping as single cell.
Ideally you also have some healthy controls in your dataset, so that you can use those to check if the mapping went well (i.e. if controls from your data are mixing well with the HLCA core (controls only)). But I'd say just give it a try, and if the mapping works well it could indeed tell you something about which cell types are different in your disease of interest (lung cancer in this case) compared to healthy tissue. You can check out the paper for examples of that, we do it with lung cancer, IPF and more. All notebooks with analysis are available on the HLCA reproducibility GitHub

Hi @LisaSikkema
I have only lung cancer cells, and the cells formed a cluster that is distinct from the reference cells when I used scArches to map the cells to the HLCA reference. The cells were close to epithelial cells, which makes sense.
I guess it's a nice visualization to show that our cells are different from normal lung cells.
Besides that, I have to think what else the latent features could tell about my data. That would these latent features be in some sense better than the ones get from e.g. Seurat's PCA. Do you think that there would be some reason to use the scArches latents instead of principal components?

@SirKuikka  I will close this issue now but feel free to re-open if you have further comments


Add ER Diagram to CONTRIBUTING.md

Merge after #1787

BTW, I checked some Github Actions for generating ER Diagrams automatically but everything seems like a lot of work to set up because they need a running database, you can't (as I understand it) just generate it directly from SQLAlchemy mappings (classes).

recheck


Add additional tests to test_parser

Description:
Add more test cases for alaska/keyword_tree.py in alaska/tests/test_parser.py

Add tests that verify found items are removed from the Alias.not_found list
Add removing found items from not_found in Alias.model_parse()
Fix path assigment operator in example.py

Related issue:
This work is a subset of #26 'Increase test coverage', but does not complete it.
Reminders

[X] Run black . to make sure the code follows the style guide.
[ ] Add tests for new features or tests that would have caught the bug that you're fixing.
[ ] If adding new functionality, add an example to the docstring, gallery, and/or tutorials.

Test Results:
Before
Name                           Stmts   Miss  Cover
--------------------------------------------------
...
alaska/keyword_tree.py           292      9    97%
...
--------------------------------------------------
TOTAL                           1341    418    69%

After
Name                           Stmts   Miss  Cover
--------------------------------------------------
...
alaska/keyword_tree.py           294      4    99%
...
--------------------------------------------------
TOTAL                           1343    413    69%

Let me know if this change could be accepted (or rejected) or
needs some additional changes before being approved and merged.
Thank you,
DC

@jessepisel , great!  Thank you for the merge. :-)


Update CocoaPods specs: added swift_version(5.0)

Hello, I'd like to submit a PR.

What's changed: Added a configuration, swift_version,  to the Cocoapod podspec file

The version, 5.0, came from the xcode project settings within the docsgen folder.

Purpose: To fix issues in integrating this pod.
Especially when using pod package mylib.podspec where mylib has a dependency on TensorFlowLiteSwift(2.9.1).

$ pod package mylib.podspec

Installing TensorFlowLiteC (2.9.1)
Installing TensorFlowLiteSwift (2.9.1)
[!] Unable to determine Swift version for the following pods:

- `TensorFlowLiteSwift` does not specify a Swift version and none of the targets (`packager`)
integrating it have the `SWIFT_VERSION` attribute set. Please contact the author or
set the `SWIFT_VERSION` attribute in at least one of the targets that integrate this pod.

Below is the podspec file used with the command above.
Pod::Spec.new do |s|
  s.name             = 'mylib'
  s.version          = '0.1.0'
  s.summary          = 'A short description of mylib.'
  s.description      = <<-DESC
TODO: Add long description of the pod here.
                       DESC
  s.homepage         = 'https://github.com/myhomepage'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { 'myname' => 'myemail' }
  s.source           = { :http => 'myurl' }
  s.ios.deployment_target = '12.0'
  s.static_framework = true
  s.source_files = 'mylib/Classes/**/*'
  s.dependency 'TensorFlowLiteSwift', '~> 2.9.1'
  s.dependency 'TensorFlowLiteSwift/CoreML', '~> 2.9.1'
  s.dependency 'TensorFlowLiteSwift/Metal', '~> 2.9.1'
  s.script_phases = [
          {
              :name => 'Download Tflite models',
              :execution_position => :before_compile,
              :shell_path => '/bin/sh',
              :script => '/bin/sh "$SRCROOT/../../RunScripts/download_models.sh"'
          }
      ]
end

@ryan-cha how does it going with merge?

how does it going with merge?

@vol-kulyk Not quite sure about the unsuccessful checks, but I'm still waiting for the review. 🤷♂

Hi @terryheo Can you please review this PR ? Thank you!

Hi @terryheo Can you please review this PR ? Thank you!


fixing script path (task #6666)

Fixing script path so it could be ran from outside the script directory

Codecov Report

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

@@            Coverage Diff            @@
##             master     #580   +/-   ##
=========================================
  Coverage     28.58%   28.58%
  Complexity     1024     1024
=========================================
  Files            89       89
  Lines          3397     3397
=========================================
  Hits            971      971
  Misses         2426     2426

Continue to review full report at Codecov.

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


Add Keywords AI (YC W24)

Thanks for the contribution! But in the current state of the PR it seems like more of an advertisement than a meaningful contribution. If you think that this is something that could benefit the OpenDevin community, I'd encourage you to either hop on our slack or open a new PR that has a more comprehensive description of the potential benefits of using keywordsai as opposed to just calling LLM providers directly.


Update doesn't install

Hello,
I tried this app today from FDroid and I was able to download but not install the SWE browser.
Here's my interaction:

When opening the app, it asks for storage permission. I allow
An update screen is shown, saying "(today's date) build is available"
I tap the double arrow, a notification starts downloading and text is switched to "Downloading the update..."
When the download finishes, the notification disappears and the text says "No update available"
Tried rechecking for updates with the refresh icon, still no update available

Also tried clearing app's data several times, disabling ad blocker, removing another SWE browser, getting this app from XDA... still nothing. Using version 1.4 of the app on Android 7.1.1 (OnePlus 3).

First check if the "unknown sources" option in security settings is enabled. If it is, then please check if the browser apk is present in the "download" folder in internal memory (that's the default download path of the app).

First check if the "unknown sources" option in security settings is enabled.
Yes, otherwise I wouldn't have been able to use the updater at all.

If it is, then please check if the browser apk is present in the "download" folder in internal memory
Yes, there is chromium-swe.apk.

that's weird, the system default apk installation process is supposed to start once the download is complete.
I'll need you to supply a logcat grabbed just after the download finishes to debug the issue further. To cause the app to reset and let you download the update again you can just clear its data in settings->app

Oh, and if in the meantime you want to start using the browser you can install the apk found in "download"

Here you go. Seems like the error starts from time 23:32:35.709.

Uninstall the app and install this one https://www.androidfilehost.com/?fid=817550096634772200. Let me know if now the update starts.

Yes, this version did fix the issue!

So the problem seems to be that the package installer on your phone has a different package name than most android devices. "com.google.android.packageinstaller" instead of "com.android.packageinstaller". This caused a problem in file permissions. I'm going to push a new update to F-Droid so if you want to install from there check in a few days. Otherwise you can keep using this version i gave to you.


New Feature: Now Playing

Hello,
when can we expect New Feature: Now Playing update?
is there any ETA for the same?
Thankyou!!!

I like to know also. Would be a great addition

You can try from this Branch.
Add this to your pub spec.yaml
flutter_carplay:
    git:
      url: https://github.com/bensalcie/flutter_carplay.git # Where to find Repo
      ref: Carplay-support-image-from-url # branch name

Call the now Now Playing Template in flutter:
(Assuming you already sent your media item to the media queue)
   await FlutterCarplay.showSharedNowPlaying(animated: true);

This branch freeze the ui when the images  from url are loaded .


fix(slots): dont stop mutating titles after an undefined Slot

Description

Type of change

[ ]  Patch: Bug (non-breaking change which fixes an issue)
[x]  Minor: New feature (non-breaking change which adds functionality)
[ ]  Major: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[ ] This is something we need to do.

rebased


[2][Easy][LandingPage+Server] Upgrade subscription feature

Currently when someone is subscribed to monthly and they want to upgrade to annual, they must wait until their subscription ends.
What we want:

A monthly subscriber clicks a button called "Upgrade to annual" on the dashboard, which upgrades their subscription to the annual plan at the end of their current period.

Info

Need to check Stripe API to see how to change subscription

can i pick this one up?

@qimcis Yessir, did u also apply to the quest by any chance? What is ur discord tag?

@qimcis Yessir, did u also apply to the quest by any chance? What is ur discord tag?

i did but i had forgotten to put this as my preference 😭 , my discord tag is @qimcis

outdated


GarnetClient Extensions

Feature request type
enhancement
Is your feature request related to a problem? Please describe
While there are few implemented commands for GarnetClient are you open to accepting PRs for implementing other commands on top of ExecuteForStringResultAsync() or ExecuteForStringArrayResultAsync()
I find myself writing some here https://github.com/OrchardCoreContrib/OrchardCoreContrib.Modules/blob/main/src/OrchardCoreContrib.Garnet/Extensions/GarnetClientExtensions.cs
Also there are two in this PR https://github.com/OrchardCoreContrib/OrchardCoreContrib.Modules/pull/127/files
Describe the solution you'd like
Add extension methods to GarnetClient
Describe alternatives you've considered
No response
Additional context
No response

/cc @TalZaccai

Yes, we are definitely open to accepting pull requests in this space. Thanks, and look forward to it!

Believe it or not yesterday I planned to start my library but I thought it be better to file an issue than hear the response, @badrishc could you please look for one of the extensions that I created if it's fine I can start push a PR
BTW shall we add it as extension methods or where should I add them, coz it's the first time to contribute here

These can be added at https://github.com/microsoft/garnet/tree/main/libs/client/GarnetClientAPI - you will see there are already files for different API categories, such as Sorted Set. You would add the new ones similarly.

Got it, I will start my PRs :)
One more thing but it might be breaking change why you are using Garnet.client namespace instead of Garnet.Client it against the namespace rules

It was just a stylistic choice. We can leave it as Garnet.client - it is fine as long as our format style does not complain.

+1 for following the standard practice of PascalCasing the namespaces.


Fix byte order detection bug on Linux 64 bit

I am not sure this is a PHP bug or not, but PHP cast<PHONE_NUMBER> to float on my server.
(PHP Version 7.2.10-0ubuntu<IP_ADDRESS>)
This bug resulting in throw 'Not MO file' exception.
I take WordPress's get_byteorder() function as reference, fixed this bug.

Sorry, I confirmd this is a ionCube bug. If source code encoded by ionCube PHP Encoder, a big int value will be cast as float not int.
No encoded file:

(but this patch can working with encoded or not encoded file.)


Introducing VortexSystem.Settings

This commit looks large, but is essentially just an abstraction of the configuration settings from the VortexSystem into it's own Settings class, with those properties replaced in VortexSystem with a single property; vortexSettings.
The changes are documented in a the updated README. Settings enables an intuitive initialisation based on preset settings, enables autocomplete for each setting (rather than relying on specifying the required parameters of the init, and getting them all in the right order), and removes the need to ever call .makeUniqueCopy.
The change necessitates changes to VortexSystem of course, but also the VortexSystem-Behaviour to ensure that the configuration settings are accessed via vortexSettings. (dynamicLookup is also added to VortexSystem for convenience).
Included here are also changes to four presets, Confetti, Fire, Fireflies and Fireworks, showing how the settings would be used for each. (A new full width Fire preview is also included showing how preset settings can be tweaked). The others remain (at least for now) with the previous VortexSystem method of initialisation.
Changing the remainder of the presets would take a matter of moments, however I did not want to update too many files at once! (In the interim, some deprecation warnings will be generated by the compiler - see below)
Because of the changes, and in particular because secondary systems are now secondary settings, this could have been a breaking change. However in the interests of backward compatibility, the old inits have been preserved, although they are now marked as deprecated.
This will show warnings in the code, but everything will continue to work.
It is evisaged that after a suitable time, agreed by Paul, the deprecated inits could be removed, and some further code cleanup completed. One such change would be modifying  the init of the VortexView to accept a Settings struct as an anonymous parameter, so that VortexView(.confetti) would call the VortexSystem.Settings.confetti preset, rather than the current VortexSystem.confetti preset, which would be removed.

Whether position is a configuration setting or not is a debatable point, because it is a property that gets modified by the 'moveTo' method in the proxy. Configuration parameters should arguably be unmodifiable. One could certainly argue that initialPosition could be a valid configuration setting, and it would then require a separate position property to be held and initialised  within VortexSystem.  No changes have been made in this regard.

Thank you for this! Broadly it looks fine, but I've added various notes and questions around the code.

Changing the remainder of the presets would take a matter of moments, however I did not want to update too many files at once! (In the interim, some deprecation warnings will be generated by the compiler - see below)

There are two independent things in this pull request, which is complicatings things slightly – the move to separate settings, and trying to share tagged particle views. The former seems very good; the latter I'm really not sure about.

Because of the changes, and in particular because secondary systems are now secondary settings, this could have been a breaking change. However in the interests of backward compatibility, the old inits have been preserved, although they are now marked as deprecated. This will show warnings in the code, but everything will continue to work.

Vortex already has a v1 tagged, so we could release a v2 with breaking changes just fine. I'd prefer to remove old code entirely rather than issuing deprecation warnings, or at least make the new approach the easier approach.

Whether position is a configuration setting or not is a debatable point, because it is a property that gets modified by the 'moveTo' method in the proxy. Configuration parameters should arguably be unmodifiable. One could certainly argue that initialPosition could be a valid configuration setting, and it would then require a separate position property to be held and initialised within VortexSystem. No changes have been made in this regard.

Why should configuration parameters be unmodifiable? If someone wants confetti rate to start fast then slow down, wants to make particle bursts grow in size each time a burst is created, or wants to make the angle move constantly like a sweeping motion, all those seem reasonable.

Thankyou for taking the time for such a comprehensive review!  :D . I’ll reply to the other comments separately, but will follow your guidance here.
The new approach to creating a particle system is very easy;  just call the VortexView with a settings struct you previously created, or use a preset.   The VortexView then creates the particle systems internally, and only creates secondary systems when the spawn event creates them.  With your blessing, I'll remove the old vortex system presets.
For clarity, there is no intention to share tagged particle views; only to share presets of type VortexSystem. I did intend to share Previews of each preset for demonstration purposes within Xcode, so the anyone using those presets could see how they would look in their own applications.  Would you prefer the Previews to be removed?
Should I tag the next PR as a v2, or will you add the tag to it after(if) you merge in the changes?
Regarding the comment about position, size and speed being configuration settings that can change over the course of a systems life, I agree with you that it’s ok for these to change, - I just wanted to raise this in case it was a concern.
I’m excited about these changes :)
-Andrew

On 7 Dec 2024, at 12:11, Paul Hudson @.***> wrote:
Thank you for this! Broadly it looks fine, but I've added various notes and questions around the code.
Changing the remainder of the presets would take a matter of moments, however I did not want to update too many files at once! (In the interim, some deprecation warnings will be generated by the compiler - see below)
There are two independent things in this pull request, which is complicatings things slightly – the move to separate settings, and trying to share tagged particle views. The former seems very good; the latter I'm really not sure about.
Because of the changes, and in particular because secondary systems are now secondary settings, this could have been a breaking change. However in the interests of backward compatibility, the old inits have been preserved, although they are now marked as deprecated. This will show warnings in the code, but everything will continue to work.
Vortex already has a v1 tagged, so we could release a v2 with breaking changes just fine. I'd prefer to remove old code entirely rather than issuing deprecation warnings, or at least make the new approach the easier approach.
Whether position is a configuration setting or not is a debatable point, because it is a property that gets modified by the 'moveTo' method in the proxy. Configuration parameters should arguably be unmodifiable. One could certainly argue that initialPosition could be a valid configuration setting, and it would then require a separate position property to be held and initialised within VortexSystem. No changes have been made in this regard.
Why should configuration parameters be unmodifiable? If someone wants confetti rate to start fast then slow down, wants to make particle bursts grow in size each time a burst is created, or wants to make the angle move constantly like a sweeping motion, all those seem reasonable.
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#issuecomment-2525090542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIXUFOOWZFZZKWGWN7T2ELQYNAVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRVGA4TANJUGI.
You are receiving this because you authored the thread.

Agreed. I’ll do that.

On 7 Dec 2024, at 11:48, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/Settings/Settings.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874403654:

@@ -0,0 +1,314 @@
+//
+// Settings.swift
+// Vortex
+// https://www.github.com/twostraws/Vortex
+// See LICENSE for license information.
+//

+import SwiftUI
+
+extension VortexSystem {
I'd be happy to move this whole struct outside VortexSystem and just call it VortexSettings; it's a bit wordy as-is.
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486485895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIU7VSZYR3IO7GIEFIT2ELOBVAVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DKOBZGU.
You are receiving this because you authored the thread.

Ahhh. I see now what you meant about sharing prebuilt views - the symbol views.  I’ll think about this some more.

On 7 Dec 2024, at 11:42, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/Views/VortexView.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874402937:

@@ -55,6 +56,32 @@ public struct VortexView: View where Symbols: View {
self.symbols = symbols()
}

/// Creates a new VortexView from a pre-configured particle system, along with any required  SwiftUI
/// views needed to render particles. Sensible defaults will be used if no parameters are passed.
/// - Parameters:
///   - settings: A vortexSettings struct that should be used to generate a particle system.
///               Typically this will be set using a preset static struct, e.g. .fire. Defaults to a simple system.
///   - targetFrameRate: The ideal frame rate for updating particles. Defaults to 60 if not specified. (use 120 on Pro model iPhones/iPads )
///   - symbols:  A closure that should return a tagged group of SwiftUI views to use as particles.
///               If not specified, a default group of three views tagged with .circle,.confetti and .sparkle will be used.
public init(

   settings: VortexSystem.Settings = .init(),

   targetFrameRate: Int = 60,

   @ViewBuilder symbols: () -> Symbols = {

       Group {

   Image.circle

I appreciate the problem this is trying to solve, but I'm not sure it's really that practical – using images rather than shapes has a significant performance impact, and each system uses different variations. For example, .confetti adds a square shape and doesn't use plus lighter, .rain uses 32-point circles without plus lighter, fire adds a blur over 32-point circle, etc.
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486485081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIXV2W42O257O3PCSMD2ELNK3AVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DKMBYGE.
You are receiving this because you authored the thread.

Agreed. Will change to:  _ settings = VortexSettings(),
I’ll remove the old VortexSystem init .

On 7 Dec 2024, at 11:31, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/Views/VortexView.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874401456:

@@ -55,6 +56,32 @@ public struct VortexView: View where Symbols: View {
self.symbols = symbols()
}

/// Creates a new VortexView from a pre-configured particle system, along with any required  SwiftUI
/// views needed to render particles. Sensible defaults will be used if no parameters are passed.
/// - Parameters:
///   - settings: A vortexSettings struct that should be used to generate a particle system.
///               Typically this will be set using a preset static struct, e.g. .fire. Defaults to a simple system.
///   - targetFrameRate: The ideal frame rate for updating particles. Defaults to 60 if not specified. (use 120 on Pro model iPhones/iPads )
///   - symbols:  A closure that should return a tagged group of SwiftUI views to use as particles.
///               If not specified, a default group of three views tagged with .circle,.confetti and .sparkle will be used.
public init(

   settings: VortexSystem.Settings = .init(),

I think we should probably use _ settings so that we get VortexView(.confetti). I'd be happy to rename the older one and mark it deprecated if it's causing confusion, but I want the newer, correct option to be the simplest.
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486483566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBITJODVAMPC5PPLAUPT2ELMBXAVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DGNJWGY.
You are receiving this because you authored the thread.

Agreed.

On 7 Dec 2024, at 11:29, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In README.md https://github.com/twostraws/Vortex/pull/29#discussion_r1874401173:

-VortexView(.fire) {

Circle()

   .fill(.white)

   .blendMode(.plusLighter)

   .blur(radius: 3)

   .frame(width: 32)

   .tag("circle")

+struct ContentView: View {

var body: some View {

   let fireSettings = VortexSystem.Settings(from: .fire ) { settings in

It's generally not a good idea to mix up logic and layout in the body property, so I think for the README it might be a better idea to pull this settings object out into its own property.
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486483274, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIVEXLUWD7JY4WNM6DD2ELLYTAVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DGMRXGQ.
You are receiving this because you authored the thread.

Agreed

On 7 Dec 2024, at 11:27, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/System/VortexSystem.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874400899:

public var angularSpeed: SIMD3

/// How much variation to allow in particle spin speed.
public var angularSpeedVariation: SIMD3

// These properties determine how particles are drawn.
/// What colors to use for particles made by this system. If randomRamp is used
/// then this system picks one possible color ramp to use.
public var colors: ColorMode {

   didSet {

       if case let .randomRamp(allColors) = colors {

           self.selectedColorRamp = Int.random(in: 0..<allColors.count)

       }

/// The configuration settings for a VortexSystem
var vortexSettings: VortexSystem.Settings
I think this should just be settings.

—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486483029, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBITN7Z6YH32IHG35AYL2ELLRXAVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DGMBSHE.
You are receiving this because you authored the thread.

It doesn’t offer much, that’s true. The only thing it does is allow the entire settings, including secondary settings, to be created within the closure.
Like the example below. It’s a very marginal thing however, so I’m happy to remove it if you don’t like the shape.
public static let fireworks = VortexSettings { settings in
settings.tags = ["circle"]
settings.position = [0.5, 1]
settings.birthRate = 2
settings.emissionLimit = 1000
settings.speed = 1.5
settings.speedVariation = 0.75
settings.angleRange = .degrees(60)
settings.dampingFactor = 2
settings.size = 0.15
settings.stretchFactor = 4
    var sparkles = VortexSystem.Settings { sparkle in
        sparkle.tags = ["sparkle"]
        sparkle.spawnOccasion = .onUpdate
        sparkle.emissionLimit = 1
        sparkle.lifespan = 0.5
        sparkle.speed = 0.05
        sparkle.angleRange = .degrees(180)
        sparkle.size = 0.05
    }

    var explosions = VortexSystem.Settings { explosion in
        explosion.tags = ["circle"]
        explosion.spawnOccasion = .onDeath
        explosion.position = [0.5, 0.5]
        explosion.birthRate = 100_000
        explosion.emissionLimit = 500
        explosion.speed = 0.5
        explosion.speedVariation = 1
        explosion.angleRange = .degrees(360)
        explosion.acceleration = [0, 1.5]
        explosion.dampingFactor = 4
        explosion.colors = .randomRamp(
            [.white, .pink, .pink],
            [.white, .blue, .blue],
            [.white, .green, .green],
            [.white, .orange, .orange],
            [.white, .cyan, .cyan]
        )
        explosion.size = 0.15
        explosion.sizeVariation = 0.1
        explosion.sizeMultiplierAtDeath = 0
    }

    settings.secondarySettings = [sparkles, explosions]
}

On 7 Dec 2024, at 11:26, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/Settings/Settings.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874400820:

   /// - Parameters:

   ///  - from: `VortexSettings`

   ///  The base settings struct to be used as a base. Defaullt settings will be used if not supplied.

   ///  - : @escaping (inout VortexSettings)->Void

   ///  An anonymous closure which will modify the settings supplied in the first parameter

   /// e.g.

   /// ```swift

   /// let newFireSettings = VortexSystem.Settings(from: .fire ) { settings in

   ///         settings.position = [ 0.5, 1.03]

   ///         settings.shape = .box(width: 1.0, height: 0)

   ///         settings.birthRate = 600

   ///     }

   /// ```

   public init(

       from base: VortexSystem.Settings = VortexSystem.Settings(),

       _ modifiedBy: @escaping (_: inout VortexSystem.Settings) -> Void

This is an odd shape for an initializer. What does it offer over code like this:
var settings = VortexSystem.Settings(from: .fire)
settings.idleDuration = 3
settings.angle = .whatever
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486482946, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIWI475YXRO2XRRNPCL2ELLO5AVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DEOJUGY.
You are receiving this because you authored the thread.

Re. Odd shaped initialiser:
The difference is highlighted more succinctly in use between these two Previews, which both do the same thing. A closure is required in both cases, but the second one seems neater, and avoids the
 { ..return..}()  pattern which I hoped to avoid. What do you think?
versus
#Preview("Demonstrates the fire preset with attraction") {
/// Here we modify the default fire settings to extend it across, and just slightly below,  the bottom of the screen
let floorOnFire:VortexSettings = {
var settings = VortexSettings(basedOn: .fire)
settings.position = [0.5, 1.02]
settings.shape = .box(width: 1.0, height: 0)
settings.birthRate = 600
return settings
}()
VortexView(floorOnFire) {
Circle()
.fill(.white)
.frame(width: 32)
.blur(radius: 3)
.blendMode(.plusLighter)
.tag("circle")
}
}
versus
#Preview("Demonstrates the fire preset with attraction") {
/// Here we modify the default fire settings to extend it across, and just slightly below,  the bottom of the screen
let floorOnFire = VortexSettings(basedOn: .fire) { settings in
settings.position = [0.5, 1.02]
settings.shape = .box(width: 1.0, height: 0)
settings.birthRate = 600
}
VortexView(floorOnFire) {
Circle()
.fill(.white)
.frame(width: 32)
.blur(radius: 3)
.blendMode(.plusLighter)
.tag("circle")
}
}

On 7 Dec 2024, at 15:18, Gn ail @.***> wrote:
It doesn’t offer much, that’s true. The only thing it does is allow the entire settings, including secondary settings, to be created within the closure.
Like the example below. It’s a very marginal thing however, so I’m happy to remove it if you don’t like the shape.
public static let fireworks = VortexSettings { settings in
settings.tags = ["circle"]
settings.position = [0.5, 1]
settings.birthRate = 2
settings.emissionLimit = 1000
settings.speed = 1.5
settings.speedVariation = 0.75
settings.angleRange = .degrees(60)
settings.dampingFactor = 2
settings.size = 0.15
settings.stretchFactor = 4
    var sparkles = VortexSystem.Settings { sparkle in
        sparkle.tags = ["sparkle"]
        sparkle.spawnOccasion = .onUpdate
        sparkle.emissionLimit = 1
        sparkle.lifespan = 0.5
        sparkle.speed = 0.05
        sparkle.angleRange = .degrees(180)
        sparkle.size = 0.05
    }

    var explosions = VortexSystem.Settings { explosion in
        explosion.tags = ["circle"]
        explosion.spawnOccasion = .onDeath
        explosion.position = [0.5, 0.5]
        explosion.birthRate = 100_000
        explosion.emissionLimit = 500
        explosion.speed = 0.5
        explosion.speedVariation = 1
        explosion.angleRange = .degrees(360)
        explosion.acceleration = [0, 1.5]
        explosion.dampingFactor = 4
        explosion.colors = .randomRamp(
            [.white, .pink, .pink],
            [.white, .blue, .blue],
            [.white, .green, .green],
            [.white, .orange, .orange],
            [.white, .cyan, .cyan]
        )
        explosion.size = 0.15
        explosion.sizeVariation = 0.1
        explosion.sizeMultiplierAtDeath = 0
    }

    settings.secondarySettings = [sparkles, explosions]
}

On 7 Dec 2024, at 11:26, Paul Hudson @.***> wrote:
@twostraws commented on this pull request.
In Sources/Vortex/Settings/Settings.swift https://github.com/twostraws/Vortex/pull/29#discussion_r1874400820:

   /// - Parameters:

   ///  - from: `VortexSettings`

   ///  The base settings struct to be used as a base. Defaullt settings will be used if not supplied.

   ///  - : @escaping (inout VortexSettings)->Void

   ///  An anonymous closure which will modify the settings supplied in the first parameter

   /// e.g.

   /// ```swift

   /// let newFireSettings = VortexSystem.Settings(from: .fire ) { settings in

   ///         settings.position = [ 0.5, 1.03]

   ///         settings.shape = .box(width: 1.0, height: 0)

   ///         settings.birthRate = 600

   ///     }

   /// ```

   public init(

       from base: VortexSystem.Settings = VortexSystem.Settings(),

       _ modifiedBy: @escaping (_: inout VortexSystem.Settings) -> Void

This is an odd shape for an initializer. What does it offer over code like this:
var settings = VortexSystem.Settings(from: .fire)
settings.idleDuration = 3
settings.angle = .whatever
—
Reply to this email directly, view it on GitHub https://github.com/twostraws/Vortex/pull/29#pullrequestreview-2486482946, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ5JBIWI475YXRO2XRRNPCL2ELLO5AVCNFSM6AAAAABTFO5WPCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOBWGQ4DEOJUGY.
You are receiving this because you authored the thread.


Didnt work with GSAP, or Scrollmagic  (Greensock TweenMax)

Thanks for awesome code, you guys making this internet better :)

How did you solve the issue?

Yes:
You just need to call  scrollMagic scene.refresh();
var controllerMain = new ScrollMagic.Controller(); var promoWrapperAnimScene = new ScrollMagic.Scene({triggerElement: ".promo-sections-wrapper", triggerHook: 1, duration: promoWrapperHeight}) 			.setTween(".js_Fill", 1, {height: "100%", ease: Linear.easeNone}) 			.addTo(controllerMain); 		scrollbar.addListener(function (s) { 			promoWrapperAnimScene.refresh(); 		});


Using it with lichess-bot

When i try and do this it returns the error
[03/26/23 08:24:36] INFO     Backing off play_game(...) for 106.1s (chess.engine.EngineTerminatedError: engine process died unexpectedly (exit code: 255))

I fixed this but now is says move overhead error

How did you fix this?

Fix to the original error:
Make sure you are putting everything from the dist folder (using pyinstaller) into the engines folder of lichess-bot (and not the contents of the build folder).

Fixed to the overhead error:
Disable all the uci_options inside the config.yml file of lichess-bot


Drop replacebranch in favor of parseRoute

LINKED ISSUES:
Follow up to #3083

TEST URLS:
Default branch button
https://github.com/sindresorhus/refined-github/commits/incremental-tag-changelog-link
With pagnation
https://github.com/sindresorhus/refined-github/commits/incremental-tag-changelog-link?after=51975964dd72a947a51b9a7be118d75e971549d1+34
On a file
Default branch: https://github.com/sindresorhus/refined-github/blob/master/.editorconfig
https://github.com/sindresorhus/refined-github/blob/incremental-tag-changelog-link/.editorconfig
Latest tag button
https://github.com/sindresorhus/refined-github/tree/incremental-tag-changelog-link
https://github.com/sindresorhus/refined-github
On a file
Default branch: https://github.com/sindresorhus/refined-github/blob/master/.editorconfig
https://github.com/sindresorhus/refined-github/blob/incremental-tag-changelog-link/.editorconfig

SCREENSHOT:
None

parseRoute should not change. The operation is identical to what other features do.

@fregante OK
All the other features needed to change the route or something more. Here its the same function just replacing the current branch with something else.
I will change it.

Test it before asking for a review

There’s a change you can make to parseRoute to avoid these mistakes: have it export an object instead of an array.
Bonus: add a toString function to that object to allow stringification without having the user call join('/')

How does the , toString()} work I get a syntax error when I try

{
	toString() {
		return `/${user}/${repo}/.............`
	}
}

...Looks at the branch https://github.com/sindresorhus/refined-github/tree/parser...
@fregante I am in middle of testing. I want to just make sure that I did what you wanted before I continue.

That's right

You can take this opportunity to move this function to its own file
source/github-helpers/parse-route.ts

What a messy merge

@fregante that review came in very funny.
I cant apply any suggestions

@fregante I tested this out seems to be fully working.
Side note: Deep reblame will sometimes fail if there is an open PR. I am not sure fully why, but there can be more than one PR associated with the commit.
See all the blame cases in https://github.com/sindresorhus/refined-github/pull/3083.
I have a way to fix it. But I will leave it for another pr.


split the single main template to two: one for new vnet and one for existing vnet

not necessarily required nor relevant to project heartbeat calculation improvement based on heartbeat request sequence and timestamp
removed from project development list for now.


Update Updating_Legacy_JSON.md [Documentation]

I updated Updating_Legacy_JSON.md

It's been two days, so I think it is safe to merge.


Fix undeploy hanging issue

Issues Resolved
This PR should resolve #2419
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

{"error":{"root_cause":[{"type":"status_exception","reason":"Model cannot be deleted in deploying or deployed state. Try undeploy model first then delete"}],"type":"status_exception","reason":"Model cannot be deleted in deploying or deployed state. Try undeploy model first then delete"},"status":400}

Seems like your fix is already having this issue?


Energy Controls are not functional

Checklist

[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue

Reproduction steps

Calling commands from the GUI

Debug logs
No response

https://github.com/Teslemetry/python-tesla-fleet-api/releases/tag/v0.3.1 Fixes the underlying library issue
The next release will bump and fix this issue.

This should be fixed in https://github.com/Teslemetry/hacs-teslemetry/releases/tag/v1.4.2

I couldn't reopen this issue.. However, two energy controls are still not functional:

Allow Charging from Grid &
Exports Allowed

Screen recording 2024-02-10 17.10.54.webm
Screen recording 2024-02-10 16.58.37.webm

Some logs now to backup analysis:
Set Backup Reserve to 40%
2024-02-11 19:20:12.053 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/energy_sites/XX/backup
2024-02-11 19:20:12.053 DEBUG (MainThread) [tesla_fleet_api] Body: {'backup_reserve_percent': 40}
2024-02-11 19:20:12.566 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/energy_sites/XX/live_status
2024-02-11 19:20:13.316 DEBUG (MainThread) [tesla_fleet_api] Response Status: 200
2024-02-11 19:20:13.317 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': {'solar_power': 0, 'energy_left': 23081.210526315786, 'total_pack_energy': 40737, 'percentage_charged': 56.65908271673364, 'backup_capable': True, 'battery_power': 1070, 'load_power': 1070, 'grid_status': 'Active', 'grid_services_active': False, 'grid_power': 0, 'grid_services_power': 0, 'generator_power': 0, 'island_status': 'on_grid', 'storm_mode_active': False, 'timestamp': '2024-02-11T19:20:12+10:00', 'wall_connectors': [{'din': 'XX', 'vin': 'XX', 'wall_connector_state': 5, 'wall_connector_fault_state': 2, 'wall_connector_power': 0}, {'din': 'XX', 'vin': 'XX', 'wall_connector_state': 1, 'wall_connector_fault_state': 8, 'wall_connector_power': 451.1166}]}}
2024-02-11 19:20:13.317 DEBUG (MainThread) [custom_components.teslemetry] Finished fetching Teslemetry Energy Site Live data in 0.751 seconds (success: True)
2024-02-11 19:20:13.912 DEBUG (MainThread) [tesla_fleet_api] Response Status: 200
2024-02-11 19:20:13.913 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': {'code': 201, 'message': 'Updated'}}
2024-02-11 19:20:13.913 DEBUG (MainThread) [custom_components.teslemetry] Command result: {'response': {'code': 201, 'message': 'Updated'}}
2024-02-11 19:20:13.914 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472347049280] 'result'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 240, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2279, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2316, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 892, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 962, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/number/__init__.py", line 111, in async_set_value
    await entity.async_set_native_value(native_value)
  File "/config/custom_components/teslemetry/number.py", line 214, in async_set_native_value
    await self.handle_command(self.entity_description.func(self.api, value))
  File "/config/custom_components/teslemetry/entity.py", line 86, in handle_command
    if not result["response"]["result"]:
           ~~~~~~~~~~~~~~~~~~^^^^^^^^^^
KeyError: 'result'

Switch Allow exports:
2024-02-11 19:20:29.672 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/energy_sites/XXX/grid_import_export
2024-02-11 19:20:29.672 DEBUG (MainThread) [tesla_fleet_api] Body: {'disallow_charge_from_grid_with_solar_installed': True}
2024-02-11 19:20:31.333 DEBUG (MainThread) [tesla_fleet_api] Response Status: 200
2024-02-11 19:20:31.334 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': ''}
2024-02-11 19:20:31.334 DEBUG (MainThread) [custom_components.teslemetry] Command result: {'response': ''}
2024-02-11 19:20:31.335 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472347049280] string indices must be integers, not 'str'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 240, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2279, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2316, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 892, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 962, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/config/custom_components/teslemetry/switch.py", line 169, in async_turn_off
    await self.handle_command(self.entity_description.off_func(self.api))
  File "/config/custom_components/teslemetry/entity.py", line 86, in handle_command
    if not result["response"]["result"]:
           ~~~~~~~~~~~~~~~~~~^^^^^^^^^^
TypeError: string indices must be integers, not 'str'

Right, so energy APIs don't respond the same was as vehicle APIs. Should be an easy fix.
Do you have any idea what an error response looks like? Basically the check I'm doing for vehicles is cases where we return 200 but the command was rejected, for example charging without being plugged in.

I don't think we get error responses ;-(  You just notice it hasn't changed on the next status polling, which is very sloppy.
The response is also terrible if it is successful:
{"response":""}

The documentation states you should get more ;-(
https://developer.tesla.com/docs/fleet-api#grid_import_export
{
 "response": {
  "code": 204,
  "message": "Updated"
 }
}

Can you give https://github.com/Teslemetry/hacs-teslemetry/releases/tag/v1.5.0 a try and let me know if it works any better.

Loaded up 1.5.0, the error messages have gone, but the switches are still bouncing around per my videos above.
I'll see if I can get some debug logs later.

Are the problems only related to the grid_import_export commands now? I do wonder if I have to send both values even though the documentation says they are optional. The best way to do this is either A) give me permission to randomly issue commands to your powerwall, or B) use something like https://hoppscotch.io/ to send the commands to Teslemetry directly and see what does and doesnt work.

No there are a range of issues.
I have a TESLA_API_TOKEN as well, and the curl commands work with just one value.
See video below, controlling via curl I switch to pv_only exports, site info is switched immediately, custom components switches after a few moments and Telemetry select is never switched and is still reading Battery when the mode has switched to pv_only:
Screen recording 2024-02-12 21.55.48.webm
Next video I try to switch from Battery to SolarOnly exports via Teslemetry, but the command isn't registered and Teslemerty switches itself back to Battery.
Screen recording 2024-02-12 22.02.01.webm
Happy to set you up with a HA login on my machine for testing.

1.5.8: Allow Charging from Grid switch fails:
2024-02-18 20:25:56.483 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [281472482639168] 'TeslemetryChargeFromGridSwitchEntity' object has no attribute 'entity_description'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 240, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2279, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2316, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 892, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 962, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/config/custom_components/teslemetry/switch.py", line 246, in async_turn_on
    self.set((self.entity_description.key, True))
              ^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'TeslemetryChargeFromGridSwitchEntity' object has no attribute 'entity_description'

1.5.8: off_grid_reserve
Allows me to change the setting via your slider, even gets a postive response:
2024-02-18 20:29:43.344 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/energy_sites/2252097574301386/off_grid_vehicle_charging_reserve
2024-02-18 20:29:43.345 DEBUG (MainThread) [tesla_fleet_api] Body: {"off_grid_vehicle_charging_reserve_percent": 12}
2024-02-18 20:29:45.186 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': {'off_grid_vehicle_charging_reserve_percent': 12}}
2024-02-18 20:29:45.186 DEBUG (MainThread) [custom_components.teslemetry] Command result: {'response': {'off_grid_vehicle_charging_reserve_percent': 12}}

But then during the next status update I get:
'off_grid_vehicle_charging_reserve_supported': False

off_grid_reserve should no longer show up when unsupported, and Storm mode should be fixed.

Energy controls working well now.


Version String in Device.java not updated dynamically from BuildConfig

See Device - there is a version string header being sent to the service whose value is incorrect (or is easy to accidentally leave incorrect) because it is not dynamically updated.

/cc @kreedula

This is now updated from the command params
https://github.com/AzureAD/microsoft-authentication-library-common-for-android/commit/54773dcf0194046a50114018fa3415788f19e263#diff-458f0d76d8a626d6c9d4ce12690ead9e517bedaae23490bb01ce956227f98205R177


Possible open source icons for layout?

Pretty simple icon set, might match the layout if we go minimalist?
https://useiconic.com/open/ (shared under MIT license)

Great! Thank you for sharing. Here is another source which I used before, and it works great: http://fortawesome.github.io/Font-Awesome/icons/


Update localstack (#5283)

Which issue does this PR close?

Might help with #5283
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Merging as just updates a CI dependency


Trying to colorize the indent line and space

I am trying to have two different blends one for the line and one for the space. I am not sure how to do it but so far this is what I have and it doesn't seem to work. All I get is the white indentation line.
vim.opt.termguicolors = true
vim.cmd [[highlight IndentBlanklineIndent1 guifg=#E06C75 blend=70 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent2 guifg=#E5C07B blend=70 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent3 guifg=#98C379 blend=70 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent4 guifg=#56B6C2 blend=70 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent5 guifg=#61AFEF blend=70 gui=nocombine]]
vim.cmd [[highlight IndentBlanklineIndent6 guifg=#C678DD blend=70 gui=nocombine]]

vim.cmd [[highlight IndentSpaceIndent1 guibg=#E06C75 blend=30 gui=nocombine]]
vim.cmd [[highlight IndentSpaceIndent2 guibg=#E5C07B blend=30 gui=nocombine]]
vim.cmd [[highlight IndentSpaceIndent3 guibg=#98C379 blend=30 gui=nocombine]]
vim.cmd [[highlight IndentSpaceIndent4 guibg=#56B6C2 blend=30 gui=nocombine]]
vim.cmd [[highlight IndentSpaceIndent5 guibg=#61AFEF blend=30 gui=nocombine]]
vim.cmd [[highlight IndentSpaceIndent6 guibg=#C678DD blend=30 gui=nocombine]]
vim.opt.list = true

require("indent_blankline").setup {
    char_highlight_list = {
        "IndentBlanklineIndent1",
        "IndentBlanklineIndent2",
        "IndentBlanklineIndent3",
        "IndentBlanklineIndent4",
        "IndentBlanklineIndent5",
        "IndentBlanklineIndent6",
    },
    space_char_highlight_list = {
        "IndentSpaceIndent1",
        "IndentSpaceIndent2",
        "IndentSpaceIndent3",
        "IndentSpaceIndent4",
        "IndentSpaceIndent5",
        "IndentSpaceIndent6",
    },
    show_trailing_blankline_indent = false,
    show_current_context = true,
    show_current_context_start = true,
}

That config works fine for me. Maybe your highlight groups get overwritten somewhere?
You can check with :verbose highlight IndentBlanklineIndent1

This means the highlight groups were cleared. Probably from your color scheme.

Thanks, I appreciate the help! I got it to work now. I should have guessed this but configuring everything while being new to this got me confused.


Fix UnsupportedOperation error while alert categorization in BucketLevel monitor

Issue #, if available:
https://github.com/opensearch-project/alerting/issues/254
Description of changes:
toMap()  has special implementation when size is 1 and returns a readOnly map, which causes trouble later in the code while modifying this map. Explicitly converting it to a MutableMap
public fun <K, V> Iterable<Pair<K, V>>.toMap(): Map<K, V> {
    if (this is Collection) {
        return when (size) {
            0 -> emptyMap()
            1 -> mapOf(if (this is List) this[0] else iterator().next())
            else -> toMap(LinkedHashMap<K, V>(mapCapacity(size)))
        }
    }
    return toMap(LinkedHashMap<K, V>()).optimizeReadOnlyMap()
}

CheckList:
[ ] Commits are signed per the DCO using --signoff
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #428 (b73355b) into main (5a2ac0e) will decrease coverage by 0.05%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##               main     #428      +/-   ##
============================================
- Coverage     77.00%   76.95%   -0.06%
  Complexity      177      177
============================================
  Files           165      165
  Lines          8207     8206       -1
  Branches       1208     1209       +1
============================================
- Hits           6320     6315       -5
- Misses         1293     1296       +3
- Partials        594      595       +1

Impacted Files
Coverage Δ

...ain/kotlin/org/opensearch/alerting/AlertService.kt
78.30% <0.00%> (-0.58%)
:arrow_down:

...nationmigration/DestinationMigrationCoordinator.kt
63.82% <0.00%> (-4.26%)
:arrow_down:

...ing/model/destination/DestinationContextFactory.kt
75.00% <0.00%> (-3.58%)
:arrow_down:

...destinationmigration/DestinationConversionUtils.kt
70.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

Is it possible to add a test to check for the fix? If not, did you try to reproduce the scenario from the issue manually and confirm that it's not happening anymore?

Added unit test

Is it possible to add a test to check for the fix? If not, did you try to reproduce the scenario from the issue manually and confirm that it's not happening anymore?

Looks like the CI workflow failed on some flaky test for the BWC test that I haven't seen before. The assertion implies there were two nodes in the cluster and not three. We can make a note of it and merge in for now since it's not related to this change.


ng-template support

Hi,
i would like to know if it would be possible to somehow dynamically insert ng-template via dynamic hooks?
Thank you in advance.

Hey there,
if you are trying to use ng-template/ng-container in the content string, you can't, unfortunately. These are Angular template syntax features (much like ngIf, ngFor, etc.) and therefore won't work. Under the hood, this library is rather simple and really just parses the content string for component selectors and nothing else.
Depending on what you are trying to do, however, there may be other ways to achieve the desired result. You could swap out the whole content string with a version that uses a different template to rerender everything (not exactly efficient).
Or you could perhaps write a simple custom ng-container component that is loaded as a dynamic hook and that accepts the template as a string input (you could pass it in via the context object). Then in that component, have another nested <ngx-dynamic-hooks>-component that just renders this "template". Changing the template in the context object would then automatically just rerender that specific part.


RedissonBoundedBlockingQueue  delete  bug

Expected behavior
Actual behavior
Steps to reproduce or test case

Redis version
6.2.6
Redisson version
3.23.1
Redisson configuration

Unable to reproduce. You need to provide the test code

Unable to reproduce. You need to provide the test code

RedissonBoundedBlockingQueue.delete is not added NameMapper

Unable to reproduce. You need to provide the test code

set NameMapper after , key of delete is inconsistent with that of try.
Failed to set capacity again after deletion

KeyPrefixHandler isn't a part of Redisson. Please share the code instead of screenshots.

KeyPrefixHandler isn't a part of Redisson. Please share the code instead of screenshots.

NameMapper spliced a prefix
public class KeyPrefixHandler implements NameMapper {

    private final String keyPrefix;

    public KeyPrefixHandler(String keyPrefix) {
        //前缀为空 则返回空前缀
        this.keyPrefix = StringUtils.isBlank(keyPrefix) ? "" : keyPrefix + ":";
    }

    /**
     * 增加前缀
     */
    @Override
    public String map(String name) {
        if (StringUtils.isBlank(name)) {
            return null;
        }
        if (StringUtils.isNotBlank(keyPrefix) && !name.startsWith(keyPrefix)) {
            return keyPrefix + name;
        }
        return name;
    }

    /**
     * 去除前缀
     */
    @Override
    public String unmap(String name) {
        if (StringUtils.isBlank(name)) {
            return null;
        }
        if (StringUtils.isNotBlank(keyPrefix) && name.startsWith(keyPrefix)) {
            return name.substring(keyPrefix.length());
        }
        return name;
    }

}

After adding the prefix, there is really a problem with deleting it. One less data was deleted, resulting in the inability to reallocate capacity. I hope this can be fixed

Fixed. Thanks for report


Modal removes openClass before the modal close animation has finished

Bug description:
When using an ng-leave animation on the modal dialog the modal open class is removed at the start of the animation rather than at the end of the animation. This results in issues where you're using the open class to hide overflow on the body etc which get removed before the modal is closed and end up with a nasty flickering of the scrollbar in this example. Instead the modal open class should be removed after the animation.
Example
http://plnkr.co/edit/A8YZeacWFK4yP6zMIIjY?p=preview
In this example the background is red while the open class is added to the body, you'll notice that the open class is removed at the start of the leave animation instead of when the animation has completed.
Version of Angular, UIBS, and Bootstrap
Angular: 1.5.3
UIBS: 1.3.3
Bootstrap: N/A

@cleavera, i've updated the relevant versions in your issue descriptions as 0.10.0 of UIBS is from January of 2014, or when Angular 1.2.9 was released and your plunker was using relatively recent (if not THE most) versions of those two libraries.
I did notice, however, you neglected to add the Bootstrap CSS which changes things a bit.  Can you please update your plunker to include the latest Bootstrap CSS and fix the issues with it before we take a look at this?  Thanks

Hi @icfantv I forgot to mention I have a fix for this and I intend to submit a pr on monday. I left the css out as it doesnt affect the bug (its a js issue) and its easier to demonstrate without (we also dont use your css within our system). I can still update the plunkr if needed?

@cleavera of course. and thanks.


add autoencoded assignment

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

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

How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] local build the book
[ ] review the artifacts from local build
[ ] local build the slides if appliable
[ ] Unit test if appliable

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have applied tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

After running, the images will be saved in the deep learning folder

It is pretty good, but still has some problems to be solved

In Acknowledge part, name hasn't linked to the writter
Now the way data stored has been changed, so the code has to change accordingly


Detecting when MapBasic window is active and a word on the Message window

I was hoping we would be able to grab the hWND from MapInfo using the WindowInfo() function.
The MapInfo window ID for the MapBasic window is 1002.
If I do the following:
print WindowInfo(1002,12) '[or WindowInfo(WIN_MAPBASIC,WIN_INFO_WND) ]
I get 0 in the Message Window, regardless of whether the window is bound to MapInfo or not.
Unfortunately also there is no specific info that we can target from AHK that would indicate the current window being the MapBasic Window. However there is the active window's text which we can get with WinGetText statement. That contains this:
<<
>>
 List

If the MapBasic window is not docked to the main application however the title of the window is indicated as "MapBasic". Therefore we can say:
WinGetTitle, TITLE, A
MapBasicWindowActive(){
    If winexist("MapBasic"){
        return TITLE = "MapBasic"
    } else {
        ;...
    }
}

The question really comes down to what we do in that ...

On a more positive note the Message window is much easier to access:
When docked:

ClassNN: RICHEDIT1
WindowInfo(1003,12) returns 1117068 (at least it returns something!)
again if not docked wintitle = "Message"

Another potential method for detecting MapBasic Window is with WindowInfo(,4-7), but it's not a good way.
It may also be possible to use the "WinFocusChangedHandler" but still we need a way of returning some information about the active control in MapInfo.

From a Discussion with the MapInfo team:
"12.5.1 is MapInfoPro 64 bit, therefore the MapBasic window is a WPF user control and does not have HWND. Wpf user control can only have HWNDSOURCE which can't be used as an HWND."
To get whether a WPF User Control is active, we may be able to use the following functions:
System.Windows.Input.FocusManager.GetFocusedElement() and System.Windows.Input.Keyboard.FocusedElement()


Update for AWS saml certs

Rather than have the AWS saml cert embedded in the j2 file, I've split it out to a local yml file so it's just pulled in when needed).
There's a new command that will download and refresh the yml file that can be run at container creation time; also now run at startup and when secrets change.

PR broke - accidentally pulled in unrelated changes with a minor update.  Will close and re-open.


docs(card): explain element vs pattern

What I did

added an explanation on the card pattern page about rh-card element vs card patterns

Notes to Reviewers
Design should review the approach taken here and comment. It seems to me that this page could use some prose for each pattern usage guidelines etc)

@bennypowers looks like this PR is waiting for copy/content, eh?
TBD on who picks this up.
CC: @hellogreg @coreyvickery @marionnegp

Yeah, I think we can move the "Variants" section to the card pattern page. We might also want to add a link to the card pattern page in the "Other components" section of the card element docs.

@marionnegp I've elaborated as much as seemed reasonable, but it wasn't clear to me how to implement most of the patterns listed here. i think we should pair on this, or if you have examples of the patterns in question, please link to them

@marionnegp @hellogreg any remaining thoughts on this PR?
We should try to merge this soon, since some other PRs seem to require it. We can tweak after if needed.

I believe I've added all the Card patterns except for the Video Card (which I commented out in the code).
@adamjohnson @zeroedin, We will need to discuss how to handle the play button and thumbnail in the pattern along with the described Modal solution. Do we wait for <rh-video> to handle the play button/thumbnail pattern?
@marionnegp can you look through the patterns and let me know which ones are missing?
Do we need to tackle the light gray versions of the cards too?

@markcaron, I don't think you'd need to include the light gray versions. <rh-card> should be able to use any surface color, so that would be a lot of demos to include. 😅
Looks like you've captured all the patterns, except for the one with the video thumbnail, which was discussed during today's office hours. I don't see that card pattern very often, so it might be ok to include in a minor release or the next milestone.
The bar for the title card is too tall. Is this an issue with <rh-card>?

The bar for the title card is too tall. Is this an issue with <rh-card>?

All headers as default have a margin-block-end on them (flow layer of uxdot styles).
Because the h4 is slotted in the component and is not directly styled to override page styles this style bleeds through to the element.
The way to fix it would be either:

in the pattern to explicitly pass a margin: 0; on rh-card#example-title-bar-card h4[slot]
in the component shadow styles slotted header style update margin: unset with an !important to override page style margins always in #header ::slotted(:is(h1, h2, h3, h4, h5, h6))

@marionnegp, I would think the latter of @zeroedin's proposed solutions is the answer to fixing the title bar height.

@zeroedin @marionnegp looks like we'll just need to make a change here to fix this in Charmander. Will do in another PR

I'm seeing a missing space in the image card example.
Is it possible to do add a bottom margin for something like #header ::slotted(img) + #footer? Maybe this is something to tackle in another PR?

Yeah. I left a comment in the code to solve later, once we have the image slot and other adjustments being made to card in Charmander, this should resolve itself.

The following PRs (in Charmander) will resolve the issues mentioned above:

Unset slotted header margins mentioned in the above comment about Title cards
Promo card variant creates the image slot and fixes padding/margin gaps between the slots mentioned in the Image card comment

may i suggest this path forward?

the conflicts in staging/charmander should be resolved
this branch should be rebased to staging/charmander
there resulting conflicts should be resolved

@bennypowers sorry, for some reason I didn't see your last comment before merging.


Endpoint to retrieve block proposal

When the block producer is ready to produce a new block, it needs an endpoint to request the transaction batch data from the memory pool.
### Tasks
- [ ] Add protobuf message describing the transaction batch
- [ ] Add an endpoint to the mempool to be requested by the block producer.

Closing as this is no longer relevant in the current design.


Proxy torch.nn.Parameter for PyTorch optimizers

Now Tin and Tube are subclasses of torch.nn.Module and they can have learnable parameters in the form of values in Taichi fields. However, now these values cannot be optimized by PyTorch optimizers, since they are not PyTorch-compatible. One way to make them to be PyTorch-compatible is to use a proxy torch.nn.Parameter and sync the values of torch.nn.Parameter with those in the corresponding Taichi field.
If anyone come up with a better solution, discussions and PRs are always welcomed.

Hi! I'm hoping to try doing RL with difftaichi and stannum. Any update on this issue?

Hi @rdesc ! I'm sorry, I have little time to work on this. If you can make a PR, I will be happy to review it.


add ignoreSubmodules option

This PR fixes https://github.com/microsoft/vscode/issues/88715
(now that it has for when it reaches 20 up-votes)
Purpose: Adds a setting to ignore modifications to submodules in the file tree so that large monorepos don't show numerous modifications.
Testing:

Open VSCode to a repo with submodules
Go to settings and find the "Ignore Submodules" setting
Check and uncheck the box to watch the 'M' convert to an 'S'

Thanks @joaomoreno, Any idea when this could be merged in?

Thanks! 🍻

Oh I see this hit a merge, thanks! Any idea when it will be pushed into the VSCode Repo (Ubuntu)?


Removed python 2 support (behaviors)

Maintainer merge checklist

[x] Title is descriptive/clear for inclusion in release notes.
[ ] Applied a Component: xxx label.
[ ] Applied the api-deprecation or api-break label.
[ ] Applied the release-highlight label to be highlighted in release notes.
[ ] Added to the milestone version it was merged into.
[ ] Unittests are included in PR.
[ ] Properly documented, including versionadded, versionchanged as needed.

Thank you for your contribution and working on this!
However, before you add additional commits and spend more time on this, we should pause and discuss whether we will merge it. In general it's a good idea to ask or touch base with maintainers before working on large changes to a project because it's possible it may not be accepted, which isn't a great feeling after you spent a lot of effort on it. So it's generally better to first ask whether changes would be accepted, and if agreed, then start working on them.
Now specifically about these changes. We generally don't merge these kind of changes, what people call stylistic changes. We generally only merge changes that either fix a bug or adds a feature. Only very rarely do we merge PRs that only contain stylistic changes - changes that don't fix a bug or add a feature.
The reason is that there are so many different styles to choose from, and styles change over time. So, if were to accept PRs that only change the code style, it would never end. Because styles always change and everyone has different preferences. E.g. the style of super (super(...)) you're replacing - that is not deprecated or in frowned upon, it's just an older style. But it's perfectly legal in Python3. So while it looks old, there's no reason to change it. The same for class X(object).
An additional thing is that any change, no matter how simple introduces a possibility of a bug. So when merging a bug fix or new feature this possible cost of introducing a bug is nothing compared to the cost of not applying the bug fix/feature. But when merging a stylistic change, the cost of the possible bug is tends to outweigh other consideration so hence we don't merge them for fear of causing a bug.
Finally, such changes tend to touch many files, which is discouraged for PRs because it makes review harder and is much more likely to introduce bugs.
So overall I'd be against merging this PR. But I do very much appreciate your desire to contribute and improve Kivy.

Yeah! I can understand now about stylistic changes, anyway I will try to avoid these kind of PRs

Ohhhh..... I'm a big fan of clean code
https://www.martinfowler.com/tags/clean code.html.
This PR would help to make Kivy's code cleaner, shorter and easier to
understand/read.
IMHO, rejecting stylistic changes, in general, is not a good idea for an
open-source project like Kivy.
Would you accept it, if there were a separate PR for every single
file/module? (I actually working on some code clean-ups for Kivy's layout
classes, but if you not accepting it I'll give up with these kinds of
contributions in the future)...
Am So., 2. Mai 2021 um 07:49 Uhr schrieb Kulothungan U.G <
@.***>:

Closed #7510 https://github.com/kivy/kivy/pull/7510.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kivy/kivy/pull/7510#event-4674435351, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4U63QVBISOTFZKF7Q47PDTLTYY3ANCNFSM437CIDKQ
.


Feat/ethers v6

Ethers v6 changes , so we'll be compatible with the rest of the ecosystems going forward.

try runnibg npm test and you will see the errors, probably in the next push also the CI will let you know that the code is not passing the tests 👍


Fixing #1797 via wiring beans by id not by type

Fixes #1797.
It seems M6 introduced two dependencies in TraceWebSocketAutoConfiguration:

Propagator.Setter
Propagator.Getter

Both of them are created in TraceSpringMessagingAutoConfiguration. If you look closer, they are referencing the very same object: MessageHeaderPropagation.INSTANCE
This is possible because MessageHeaderPropagation implements both Propagator.Setter and Propagator.Getter. So when the context is created there will be two beans:

traceMessagePropagationSetter
traceMessagePropagationGetter

Both of them are a Propagator.Setter and a Propagator.Getter at the same time. So we have two beans both of them are getters and setters so we have two getters and two setters at runtime and Spring does not know which one is the right one, one possible fix is wiring these beans in using their id.

Decided to go with splitting the impl into 2 - https://github.com/spring-cloud/spring-cloud-sleuth/commit/0c9106599694ba4ed820094723c3cd1815b8bfd9


Update RPO's padding rule to use that in the xHash paper

Describe your changes
Checklist before requesting a review

Repo forked and branch created from next according to naming convention.
Commit messages and codestyle follow conventions.
Relevant issues are linked in the PR description.
Tests added for new functionality.
Documentation/comments updated according to changes.

On potential thing left to consider: I believe currently hashing of empty list of elements and hashing of 8 ZERO elements will give us the same result - right? I wonder if there is a good way to fix this - just in case. Nothing immediately comes to mind though.

I think we had a similar discussion in RPO and I believe we settled on not accepting empty lists for hashing. I will think about it again to see if we can accommodate it differently.

@Al-Kindi-0 - let's rebase this PR.
Also, should we implement the rule where hashing of an empty string gives us [ZERO; 4] output?

@Al-Kindi-0 - let's rebase this PR.
Also, should we implement the rule where hashing of an empty string gives us [ZERO; 4] output?

Done!

Also, it seems like the "return default digest on empty input" as already working here, right?

Yes, had to check the bytes case, but even then it worked without complications

Lastly, could you refresh 0xPolygonMiden/miden-vm#1343 when you get a chance?

Sure thing


Developing guidelines in readme would help

Could you add some info inside readme how do you test while developing?

Dev & Test Notes added to the readme https://github.com/actionhero/ah-resque-ui/blob/master/README.md#testing--developing


Feat/final documentation

Various documentation updates to clarify deployment steps.
Fixes issue with function app model files.


bulk api is not consistent with api doc

According to the doc from here,  retry_on_conflict can't be use anymore, once use it, elasticsearch 1.7.1 will raise a error follows, and change retry_on_conflict to _retry_on_conflict  can fix it.
bulkIndexer: &{2015-08-24 17:54:24.32818233 +0800 CST: Error [IllegalArgumentException[Action/metadata line [1] contains an unknown parameter [retry_on_conflict]]] Status [500] [500] }

@chzyer rather than force elastigo to be 1.7.1, not everyone is up to date.  Can you add code that handles both cases? Can you add some tests?

@weberr13 I switch the reference to Bulk 0.9.0, it still _retry_on_conflict rather than retry_on_conflict.

What is latest version of elasticsearch that elastigo supported now and passed all the test?
Is there already exists the function that can detect the version of elasticsearch?

I will need to investigate this further.  My plan is to get all the tests passing here (I have a co-worker doing that now) then setup multiple travis jobs for the ES releases.  I'll probably do 1.5.x, 1.6.x and 1.7.x.  Once we have the tests working we can move to these sorts of changes and verify that all the versions are supported.  I have a personal interest in 1.5.x but before that I don't care as much.

OK, I looked at the code and I can't see a single instance of retry_on_conflict without the leading _.  The feature appears in .90 and it is as you have written.    Thanks for your patience.


[FEATURE] [API] Add API for Run SQL page

Code of Conduct

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

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the feature
Add API for Run SQL page
Motivation
No response
Describe the solution
No response
Additional context
No response
Are you willing to submit PR?

[ ] Yes. I can submit a PR independently to improve.
[X] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
[ ] No. I cannot submit a PR at this time.

API for Run SQL sounds really good, I hope to be able to check the corresponding SQL log and query progress (similar to beeline) on this page, is there a way to achieve this?


Exit Status Code = 0 when linting problems are found

Right now, wether problems are found during linting process or are not, the program finishes with status code 0. This could be understood as the right behavior.
However,  making the api-linter fail when problems are found could be helpful, it could help integrating api-linter into CI stages for example.  What do you think?
This capability to fail after problems are found could be activated conditionally, via input parameters to the linter.  This is a standard practice for some linter.
example:

api-linter someproto.proto -I some path --set_exit_status (print problems and then exit with code 1)
api-linter someproto.proto -I some path (print problems and exit correctly)

What do you think? I have some implementation and I could open a PR if you agree.

+1. Can you open a PR? Thanks!

My vote is for an exit status of 1 if there are problems; I agree with a switch to make it 0 if needed.

Fixed in #534.


feat: add links to owner

resolves #301 and resolves #302.

@Ngo-Tuan-Kiet @MaxSpeer What should happen when "everyone" is the owner of an item? Should everyone also be a hyperlink? Where should it lead to?

blocked until #360 is merged.

The everyone group is the only that should not have a hyperlink.
Groups should be linked to the group page (/groups//).
Personal groups should link to the users page (/profiles/).


use_history hook

This hook needs to match the react-router equivalent.
See https://github.com/idom-team/idom-router/issues/2 for more details.

React-Router no longer has a useHistory hook, so this feature is no longer relevant.


Mantle Support

I'm quite surprised one of the most popular hud changing mods isn't supported.

What do you mean by unsupported? I haven't encountered any issues with the renderer while superior shields is installed. Can you explain more?

I'm using the "Level Up HP" mod which adds more hearts with each level up. It supports mantle but superior shields doesn't see that so even though there is only one row of hearts because of mantle it still creates a space whenever you have more than 20 health.


Add missing proptype and component descriptions

Fixes issue #1278 and #1280
We should probably add a test to prevent this by traversing component-docs.json after it's built and see if there are any empty strings.

Pull Request Review checklist (do not remove)

[ ] Review the appropriate Storybook stories. Open http://localhost:9001/.
[ ] Review tests are passing in the browser. Open http://localhost:8001/.
[ ] Review markup conforms to SLDS by looking at snapshot strings.
[ ] Add year-first date and commit SHA to last-slds-markup-review in package.json and push.
[ ] Request a review of the deployed Heroku app by the Salesforce UX Accessibility Team.
[ ] Add year-first review date, and commit SHA, last-accessibility-review, to package.json and push.
[ ] While the contributor's branch is checked out, run npm run local-update within locally cloned site repo to confirm the site will function correctly at the next release.

Added #1280 "empty string" test

@futuremint Updated.


FAB doesn't reappear when using RecyclerView's swipe functionality

Since the release of a recent update, RecyclerView natively supports swipe functionality (e.g. swipe to delete) with the help of ItemTouchHelper. It's set up like this:
ItemTouchHelper.SimpleCallback simpleItemTouchCallback =
        new ItemTouchHelper
                .SimpleCallback(0, ItemTouchHelper.LEFT | ItemTouchHelper.RIGHT) {
    @Override
    public boolean onMove(RecyclerView recyclerView, RecyclerView.ViewHolder viewHolder,
                          RecyclerView.ViewHolder viewHolder1) {
        return false;
    }

    @Override
    public void onSwiped(RecyclerView.ViewHolder viewHolder, int i) {
        getActivity().getContentResolver()
                .delete(Uri.withAppendedPath(AppContentProvider.CONTENT_URI,
                        String.valueOf(viewHolder.getItemId())), null, null);
    }
};
ItemTouchHelper itemTouchHelper = new ItemTouchHelper(simpleItemTouchCallback);
itemTouchHelper.attachToRecyclerView(recyclerView);

Unfortunately, if FAB is hidden and rows are swiped away to the point when scroll bar disappears, it becomes impossible to recover it without switching orientation or restarting the app.

You could always use fab.show() method to restore the button's visibility after a finished swippe.


Mash many sequences

So, the idea is that I have many templates and many reads. Many of those templates are similar (perhaps only a 4bp difference in 5000bp). I want a method that will be able to tell me the most likely template that those reads belong to - assuming that all the different sequencing reads go to the same template, but are just a little bit noisy (1/50 random mutation or so).
This would greatly help my sequencing pipelines, and I imagine would help other sequencing pipelines.

There have been demonstrations of template matching using MASH but I'm not so sure if there's anything about extremely small variance between sequences. I'm open to maybe supporting a general template matching function as a demo to start but don't know if I want to maintain that in a stable release yet @Koeng101.


adds a middleware to add the backstage identity

Currently the scaffolder backend is parsing the backend auth token as a JWT token. This works well where:

the different parts of the backstage backend are hosted on the same server / network trust domain
the same server that is generating the tokens is also verifying them

However where the scaffolder and catalog services are hosted separately, then the token produced by backstage must be understood by the infrastructure forwarding the requests between the components of backstage. This would require a centrally managed certificate trust infrastructure or a central token issuer or something else. This is a large architectural ask.
This change expands the flexibility of the backstage identity platform by allowing any format of token for building the backstage identity for the plugins to read.
This patch also causes the scaffolder backend to use the identity from the new middleware.
It is configured by adding packages/backend/src/plugins/authentication-middleware.ts:
import { RequestHandler } from 'express';
import { PluginEnvironment } from '../types';
import {
  createMiddleware,
  jwtMiddlewareProvider,
} from '@backstage/plugin-authentication-middleware-backend';

export default async function createPlugin(
  env: PluginEnvironment,
): Promise<RequestHandler> {
  return await createMiddleware({
    logger: env.logger,
    authenticationMiddlewareProvider: jwtMiddlewareProvider,
  });
}

In packages/backend/index.ts, somewhere close to the top of the stack.
  ...
  const authenticationMiddlewareEnv = useHotMemoize(module, () =>
    createEnv('authentication-middleware'),
  );
  ...
  const apiRouter = Router();
  apiRouter.use(await authenticationMiddleware(authenticationMiddlewareEnv));

In the backend plugins you can access the identity as follows:
  router.get('/something', async (req: AuthenticatedBackstageRequest, res) => {
    const identity = req.backstage?.identity;
    res.send(identity);
  });

Signed-off-by: Brian Fletcher<EMAIL_ADDRESS>Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

codeql whack a mole.

hmm .. if the token format becomes configurable, would that raise concerns that all backend plugins needs to be able to understand the given token ?
eg. the auth middleware can be configured to correctly parse the token and attach a req.backstage.identity but all backend plugins would either need to be updated to be aware of and utilize this new prop or know how to parse the token themselves
Wouldn't configuration of the auth-backend plugin and IdentityClient (assuming plugins are using this and not parsing the raw token themselves) allow for customization of the desired token format ? or does that still run into the centralized token issuer issue?
Let me know if I've misunderstood the design here 😅

I want to suggest that all plugins, if they need the user identity of the service/user would look for the identity in the req.backstage.identity field populated by this middleware. This would mean that the token would be parsed once by the middleware and the backend plugins would not need to have this knowledge.
I was working on the assumption that backstage backend plugins, would operate on the backstage identity and not on the the token itself. So I could have got this assumption wrong. Can you explain an example of a case where a backend plugin might need to understand the token format?
auth-backend allows issuing any format of token. However today the scaffolder-backend is parsing it as a jwt token. I am proposing implementing this middleware, so that there is a pattern to follow to parse the token consistently across the application meaning the scaffolder-backend would not need to parse the token by itself in the first place.
The IdentityClient requires the issuer and the algorithms. I suppose this could be constructed in the backend and passed down to all of the plugins and that could be used to figure out the user. But currently the IdentityClient assumes that the token is jwt also. Maybe it can be changed to an interface that can be provided? Either would work I think.

Thanks for your review @kuangp

I was working on the assumption that backstage backend plugins, would operate on the backstage identity and not on the the token itself. So I could have got this assumption wrong. Can you explain an example of a case where a backend plugin might need to understand the token format?

So what I meant was for other plugins that have not been updated and are still manually parsing the token (like the scaffolder-backend prior to this change), they would not be able to understand a custom token format if said plugin has not been updated yet.
So similar to your proposal, I wonder if it makes sense as an alternative, all plugins are updated to handle tokens via const user = await identity.authenticate(token); to allow the IdentityClient be responsible for knowing how to parse out the user. That way, instead of having to install/configure this middleware + updating all plugins to read the new req.backstage?.identity field, all plugins utilize the IdentityClient (some of which already are) and integrators customize the IdentityClient through some interface as you suggested.
The benefits here would be not having to install an additional middleware package and not having each plugin loosely coupled to the semantics of the req.backstage prop provided by said middleware.

Yep having discussed similar things as a part of #11611 I'm leaning towards const data = <service>.<method>(req) being much better than decorating the request object directly. Especially with typescript it's essentially just the same amount of "work" too. You can even go and cache the result per request within the service implementation if it's doing something expensive.

I closed this in favour of the better suggestion.


Bumping CAPC to v0.4.9-rc2

Issue #, if available:
Description of changes:
Bumping CAPC version.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cherrypick release-0.13

rate limited for some reason


"Get started" link on homepage is broken

What is the issue?
On the https://dagger.io/ page there is a "Get started" link to https://docs.dagger.io/getting-started which shows "Page Not Found."

Thanks so much for spotting this @rmcloughlin! Fixed!


[BUG] Added links not showing on profile

Has this bug been raised before?

[X] I have checked "open" AND "closed" issues and this is not a duplicate

Where did you find this bug?
https://www.biodrop.io/angkul07
Version of BioDrop (for example "v1.2.3")
v2.97.6
Description
I just created my biodrop profile and it seems that the links I added from "Links" section, are not showing up on my profile. I tried multiple times but it is not working.
Steps to Reproduce
Go to biodrop.io and login into your account and go to Links section. Click on "Add Link", fill the form, turn on "Enable?" and "Pin?" and save. Thank you.
Screenshots
No response
Do you want to work on this issue?
No
If "yes" to above, please explain how you would technically implement this
No response

It seems to be working fine, I just tested it, please can you elaborate what link you are trying to add. Your profile has the GitHub link pinned ...

This is a bug, thank you for raising and verifying 💪

I found the bug, just deploying a fix now

I just tested on live and it is now working, sorry for the confusion


Updated Noah's name

Updated your name to reflect Terrace House obsession. Please merge changes.

I approve !!!


"Running Queries" Tab reports old data

The presented data could be, under certain situations, of interest BUT they are not the current "Running Queries". They are mostly "Ran Quaries". The tab title implies the current state of server is as reported, which isn't quite right.
One needs to update the state of the server using the "Get Latest" button almost EVERY time.
So I suggest

either to rename the "Tab" to somting else
or better: auto fire the "Get Latest" when user switch to the Tab. This way one REALLY gets the current state.

The tab shows snapshots of running queries at a particular point in time.  Depending on the snapshot you are looking at some of those queries will have completed and some might still be running.  So ran queries wouldn't be accurate - changing to "Running Query Snapshots" would be more accurate but quite verbose.
An option to show the latest snapshot by default instead of the list of running queries could be considered.


Update resolvconf-apt.yml

recheck

@logan2211 Can we somehow recheck this? As role is really failing for the relatively new ansible versions because of that


在构建方面不太适合新手，能否在构建上面在简单点吗

能否在vs2022上面构建

Filament should work fine with Visual Studio 2022.
Follow the prerequisites here, but make sure you have CMake version 3.21 or newer installed. To create the project, run
mkdir out
cd out
cmake -G "Visual Studio 17 2022" ..

Then open TNT.sln inside Visual Studio 2022.


MBL-808: BackingFragmentViewModel.kt to Jetpack ViewModel and RxJava2.2

📲 What
Update backing fragment view model to rxjava 2
🤔 Why
Technical Details
👀 See
no user-facing changes
📋 QA
Go through backing and pledge management flows
Story 📖
MBL-808: BackingFragmentViewModel.kt to Jetpack ViewModel and RxJava2.2

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

Comparison is base (6c857bd) 74.04% compared to head (b46ae8e) 74.04%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master    #1931   +/-   ##
=========================================
  Coverage     74.04%   74.04%
  Complexity     1968     1968
=========================================
  Files           337      337
  Lines         19649    19649
  Branches       2718     2718
=========================================
  Hits          14550    14550
  Misses         3512     3512
  Partials       1587     1587

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