0.4.2 - Bugs

Hey, seems that in some update some stuff got broken. The issues that I find are:

Despite setting segments to color: Colors.transparent, they are not transparent.
The segments are ignored entirely in the following scenario.
A new indicator appeared?

Correct (gauge_indicator: 0.4.0-dev.5):
static const List<GaugeSegment> segments = [
    GaugeSegment(from: 0, to: 20.0, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 20.0, to: 40.0, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 40.0, to: 60, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 60.0, to: 80, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 80.0, to: 100, color: someGrey, cornerRadius: Radius.circular(10)),
  ];

AnimatedRadialGauge(
        radius: MediaQuery.of(context).size.width / 2 - SizeConst.WINDOW_INSET,
        duration: const Duration(seconds: 2),
        curve: Curves.fastLinearToSlowEaseIn,
        value: value * 100,
        progressBar: GaugeProgressBar.rounded(
                gradient: GaugeAxisGradient(
                  colors: context.colorScheme.progressGradient,
                  colorStops: const [0, 0.5, 1],
                ),
                placement: GaugeProgressPlacement.inside,
              ),
        axis: GaugeAxis(
          degrees: 180,
          style: GaugeAxisStyle(
            thickness: (MediaQuery.of(context).size.width / 20).bound(18, 24),
            segmentSpacing: 8,
            blendColors: false,
            cornerRadius: const Radius.circular(20),
          ),
          segments: segments,
        ),
      )

Wrong (gauge_indicator: 0.4.2):
static const List<GaugeSegment> segments = [
    GaugeSegment(from: 0, to: 20.0, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 20.0, to: 40.0, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 40.0, to: 60, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 60.0, to: 80, color: someGrey, cornerRadius: Radius.circular(10)),
    GaugeSegment(from: 80.0, to: 100, color: someGrey, cornerRadius: Radius.circular(10)),
  ];

AnimatedRadialGauge(
        radius: MediaQuery.of(context).size.width / 2 - SizeConst.WINDOW_INSET,
        duration: const Duration(seconds: 2),
        curve: Curves.fastLinearToSlowEaseIn,
        value: value,
        axis: GaugeAxis(
          degrees: 180,
          progressBar: GaugeProgressBar.rounded(
                  gradient: GaugeAxisGradient(
                    colors: context.colorScheme.progressGradient,
                    colorStops: const [0, 0.5, 1],
                  ),
                  placement: GaugeProgressPlacement.inside,
                ),
          style: GaugeAxisStyle(
            thickness: (MediaQuery.of(context).size.width / 20).bound(18, 24),
            segmentSpacing: 8,
            blendColors: false,
            cornerRadius: const Radius.circular(20),
          ),
          segments: segments,
        ),
      )

P.s. not included in the code snippets, but I overlap the same widget twice in a stack (the one from behind is blurred and with transparent segments). This is used to achieve a glow for the filled progress bar (as can be seen in the first screenshot). In this case the whole thing glows because the transparent segments are not actually rendered as transparent anymore.

Hi @AlexDochioiu,
Thanks for opening the issue. Your gauge looks outstanding 🤩 great job 💪🏻.
Indeed, some changes have been made to the indicator widget. I have received many e-mails with complaints that the indicator is not visible and that it is challenging to start working with it. So... starting from version 0.4.0 the gauge has a default background and pointer, which allows a more intuitive start.

To disable the default background color for the axis, set the background property of the GaugeAxisStyle to  null or Colors.transparent.
To match the behavior with other Flutter widgets, the min and max values are now scaled from 0.0 to 1.0. This can be changed by setting a custom scale to the AnimatedRadialWidget. Simply, set min and max properties to 0.0 and 100.0 - to bring back the old value range, or change the from and to values of segments to match the new value range.
You can disable the pointer by setting the pointer to null

AnimatedRadialGauge(
  min: 0.0,
  max: 100.0, // Restore old value range.
  axis: GaugeAxis(
    pointer: null, // Disables the default pointer.
    style: const GaugeAxisStyle(
      background: Colors.transparent, // Disables the axis background.
      /* ... */
    ),
     /* ... */
  ),
   /* ... */
);

Let me know if this solves the problem. I may need to find a better way to provide a default style for this widget.

Hey @gonuit , thanks for the quick reply. Your solution indeed mostly solves all my problems, but I now encounter some UI misalignments which may be from minor mis-calculations or rounding errors. I adjusted the styles/etc to make them visible:

P.s. in this picture, I only use one widget (I don't overlap the two anymore for the glow).
Those mis-alignments are actually causing me issues when I overlap them with the blur (which is how I noticed in the first place)

So, it seems there's a bit more to it:

The segments mis-align on top of the background (image in previous comment)
The fill mis-aligns inside the segments (only when using GaugeProgressBar.rounded) (see new image)


YAML support

This PR

adds support for YAML as input through all CLI operations.
the CLI operations have been standardized to support templates.
templates can be in YAML or in JSON.  The default is JSON.  Use -y to use YAML.
Where positional args are taken as filename in the CLI (e.g. infrakit group commit <file> has been changed to support a template or stdin, if the positional arg is -.
Support for INI file decoding, used for decoding AWS credential files.

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

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


feat - add another solution that hlod mouse position when wheel

feat - add another solution that hlod mouse position when wheel

@nocanstillbb thank you for your contribution :) Any kind of example will someday help somebody (maybe).
I been very busy the last couple of months but just wanted you to know that I've seen this PR and I will check it as soon as I have the time to setup Qt again and check the code.

@nocanstillbb I checked it very quickly and decided to merge it. I put that in the alternative dir and added instructions to try it in the README :)
I think the example is valuable but I didn't want to put it as the main example because it's a bit longer, a bit more complex and a bit less declarative than the original code. That was my logic to preserve it in a separate dir. Hope that works for you and thank you! I appreciate the contribution :D

This PR is to thank you for sharing a sloution, you can arange it however you like

白色噪音
@.***

------------------ 原始邮件 ------------------
发件人: "Franco @.>;
发送时间: 2024年6月3日(星期一) 上午9:55
收件人: @.>;
抄送: @.>; @.>;
主题: Re: [noxware/qt-quick-flickable-and-zoomable-by-mouse-image-example] feat - add another solution that hlod mouse position when wheel (PR #1)
@nocanstillbb I checked it very quickly and decided to merge it. I put that in the alternative dir and added instructions to try it in the README :)
I think the example is valuable but I didn't want to put it as the main example because it's a bit longer, a bit more complex and a bit less declarative than the original code. That was my logic to preserve it in a separate dir. Hope that works for you and thank you! I appreciate the contribution :D
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>


Suggested Dockerfile

Thanks for the handy tool.
Please consider shipping a Dockerfile that can be used to bundle up an unprivileged container image with this tool, so users don't have to trust the sprawl of npm dependencies with access to the rest of their user accounts.
Here's one I wrote which might be useful as a starting point or for others.
FROM node:20-alpine3.16
RUN adduser -D pd
USER pd
RUN mkdir /home/pd/pd-cli
WORKDIR /home/pd/pd-cli
RUN npm install pagerduty-cli
VOLUME /home/pd/.config/pagerduty-cli
RUN mkdir -p /home/pd/.config/pagerduty-cli && chown pd:pd /home/pd/.config/pagerduty-cli
ENTRYPOINT ["npm", "exec", "--", "pd"]

# run with e.g.
#   docker run -it --rm --mount type=volume,source=pd-cli,destination=/home/pd/.config/pagerduty-cli pd-cli
#
# you will need to use the "auth:set" command the first time, and supply an api token
# created with your PD account under My Account -> User Settings -> API Access
# see https://support.pagerduty.com/docs/api-access-keys#section-generate-a-user-token-rest-api-key

Build with docker buildx build -t pd-cli . within an empty directory containing only the Dockerfile.
I then put this wrapper script in $HOME/.local/bin/pd -  you can put it anywhere convenient on your PATH:
#!/bin/bash
docker run -it --rm --mount type=volume,source=pd-cli,destination=/home/pd/.config/pagerduty-cli pd-cli "$@"

A bind-mount could be used to bind the configdir for the CLI from the user's own homedir instead of using a docker volume, but using a volume was more convenient from an unprivileged access-control point of view.
On first use, run
pd auth:set

and enter a PD API token created with your PD account under My Account -> User Settings -> API Access. Watch out, the output will be echoed to the terminal.
Subsequent runs will remember it.

Thanks very much, I got this to work on an EC2 instance.  Creating a container, running, etc.  But I ran into some strange results.  Besids the warning, I get a bunch of junk characters in the output, but then it proceeds to output the results I was looking for.
./pd user:list -k role
npm WARN config key key and cert are no longer used for most registry operations.
npm WARN config Use registry scoped keyfile and certfile instead.
npm WARN config     Example:
npm WARN config     //other-registry.tld/:keyfile=/path/to/key.pem
npm WARN config     //other-registry.tld/:certfile=/path/to/cert.crt
Getting users from PD 1/1 ≡ƒæì, 0/1 ≡ƒæÄ... done
ID      Name               Email                          Contact emails                 Contact phones Contact sms
ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ

Interesting that someone else already suggested a different Dockerfile approach:
https://github.com/martindstone/pagerduty-cli/blob/773086ad2ba071a9f588b4760e196c3fa3275729/Dockerfile

@khntst  The junk characters suggest a text encoding, locale or terminal type mismatch. Probably need to propagate some LC_ vars and TERM into the container or run it with a flag to turn off terminal char pretty-printing

Hi @khntst just catching up on this... it seems like a good idea and I will work on it the next chance I get... thanks very much for the submission

Yeah, I like the idea of limiting privs too.
Tried experimenting with various LC_ and TERM.  Not making a diff.  Then I come in today after the weekend with a fresh terminal connection (via SSM) and it just worked.  'ansi' sequences were even interpreted correctly -- symbols, colors, maybe even progress meter.  current TERM=xterm-256color, LANG=en_US.UTF-8.  nothing for LC_ stuff.  Drives me mad.  Can't figure out if I set something else permanent that fixed it.  Seems to be as-original.
So I started to run a battery of commands through it.  I can get simple lists of stuff.  But when I try to run those lists into -csv it just prints the npm version (9.6.6) and thats it, no csv record lines.  I notice a warning at the end of the simple lists:
npm notice
npm notice New minor version of npm available! 9.6.6 -> 9.7.2
npm notice Changelog: https://github.com/npm/cli/releases/tag/v9.7.2
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
Tried to re-build the container but that did not seem to improve anything.  Next I modified this line in Dockerfile (add quiet):
RUN npm install pagerduty-cli --quiet
... which then seemed to cause container to really get rebuilt.
This makes 'npm notice' messages go away from simple list output, but (9.6.6) result symptom still remains.

Ultimately I found that the built-in ssm method of establishing an ssh session exhibits the 'junk characters'.
aws ssm start-session --target
But the 'standard' ssh method does not.  With this method, the ansi coloring and characters of typical pd-cli list output display correctly.
ssh -i ~/.ssh/instance-cert.pem ec2-user@
However, I am still being stymied by this phenomenon mentioned above.
[ec2-user@ip-10-10-10-10 pd-cli]$ ./pd user:list -k 'teams[*].summary' --csv
9.6.6
... this command displays legit user list content unless I include --csv.  Then it only displays the npm version.
I also get this warning text, but it doesn't seem to be stopping normal output.
npm WARN config key key and cert are no longer used for most registry operations.
npm WARN config Use registry scoped keyfile and certfile instead.
npm WARN config     Example:
npm WARN config     //other-registry.tld/:keyfile=/path/to/key.pem
npm WARN config     //other-registry.tld/:certfile=/path/to/cert.crt

On Linux (Ubuntu) it Just worked for me. I assume your TERM env-var and termcap inside the container don't match those of the terminal emulator.


Add Notification tests to Helix

For status checks on the develop branch, please use TransportPackage-Foundation
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=57248)
and run the build against your PR branch with the default parameters.
For status checks on the main branch, please use microsoft.ProjectReunion
(https://dev.azure.com/ms/ProjectReunion/_build?definitionId=391&_a=summary)
and run the build against your PR branch with the default parameters.

/azp run TransportPackage-Foundation

/azp run TransportPackage-Foundation

I think it's just /azp run though?


fix: always add the cache policy

Description
As described in #298 the cache module has to be applied separately before creating the Runners. Terraform complains about
Error: Invalid count argument

  on ..\..\..\terraform-aws-gitlab-runner\main.tf line 323, in resource "aws_iam_role_policy_attachment" "docker_machine_cache_instance":
 323:   count      = var.cache_bucket["create"] || local.bucket_policy != "" ? 1 : 0

The "count" value depends on resource attributes that cannot be determined
until apply, so Terraform cannot predict how many instances will be created.
To work around this, use the -target argument to first apply only the
resources that the count depends on.

This PR always adds the policy to get rid of the error message during apply. As far as we know there is no use cases deploying this module without a cache. Thus we can always add the cache policy to the role.
Closes #298
Migrations required
No
Verification

[x] create a runner with a cache created separately (using the cache module). No error is shown during apply
[x] create a runner and let the module create the cache. apply shows no error.
[x] destroy everything without error

I think this MR introduces an issue with this configuration:
  cache_bucket = {
    "create" : false,
    "bucket" : aws_s3_bucket.build_cache.id
  }

(use case: S3 cache created outside of this module, because it's shared with other runner types)
When applying this, I get the error:
│ Error: Error attaching policy  to IAM Role spot-runners-instance: InvalidParameter: 1 validation error(s) found.
│ - minimum field size of 20, AttachRolePolicyInput.PolicyArn.
│
│
│   with module.ec2_runner.aws_iam_role_policy_attachment.docker_machine_cache_instance,
│   on .terraform/modules/ec2_runner/main.tf line 392, in resource "aws_iam_role_policy_attachment" "docker_machine_cache_instance":
│  392: resource "aws_iam_role_policy_attachment" "docker_machine_cache_instance" {
│

since the policy_arn is set to the empty string.

Had the same problem an hour ago, but no time to create the issue.
100% correct.
Do you have a use case for a Runner without a cache?

We do use a cache, but it's created outside of this module (I don't wish this module to create it for me).
That's because we run several Gitlab runner types (Kubernetes and docker-machine), and they should all share the same cache. So it's simpler to create the S3 resources in a separate module, then pass them to the various modules that deploy the runners.
So

I don't have a use case for a runner without a cache
but I have a use case for a runner where the cache is not created by this module 😄

@Neki It would be wonderful if you could have a quick look at my PR mentioned above. Just did the the terraform apply without creating a cache and adding a policy and it worked like a charme.


chrome animation bug

Here is a demonstration of this bug: http://codepen.io/anon/pen/PZwjGa
I have no idea what is actually happening. This only happens in chrome and works fine in firefox.

I'm getting the same issue in chrome too! It looks as though it could be an issue with the way images are loaded as and HTML seems to be working fine.

Have the same issue, any ideas?

You forgot the .owl-carousel class.


Scalar replacement of aggregates

Child of https://github.com/KhronosGroup/SPIRV-Tools/issues/457

WIP by @greg-lunarg

This work evolved into the pass InsertExtractElimPass.
Rather than do scalar replacement, which would decompose every structure member into scalar variables (resulting in significant code explosion, only to be ultimately eliminated), we took a different approach. We converted all constant index access chain loads and stores into their equivalent loads and stores plus insert and extract (LocalAccessChainConvert). So loads and stores are kept at the struct/array level, much more manageable size-wise. Once trivial loads and stores are eliminated (LocalSingleBlockElimPass, LocalSingleStoreElimPass), we are left with sequences of inserts with extracts directly operating on them. With little analysis, this pass replaces such extracts with the corresponding inserted value.
InsertExtractElimPass has been integrated. This item is done.


time input field empty

Hi All
My project version below

UI

How to solve this issue can anyone help, please

Hi, not a lot of context for this, but I was troubleshooting a similar issue and it was actually a CSS issue where my text for that time area was white on white so it was invisible. Try and find the CSS class that is interacting with that text, use the chrome dev inspector tool to see!


many users struggle with version switcher/banner handling

we use the release value and not the version value from conf.py to decide whether to show a version warning banner. We are assuming folks follow what is stated in the Sphinx docs for release:

If you don’t need the separation provided between version and release, just set them both to the same value.

the fact that folks keep stumbling around the version switcher and the warning banner suggests that either (1) what we're doing is too fragile/magic, or (2) we're not documenting it clearly enough.
Originally posted by @drammock in https://github.com/pydata/pydata-sphinx-theme/issues/1445#issuecomment-1877861639

Clarifications will go a long way to help with this feature. I've been banging my head against it for about a day. I started digging into the JS and realized that the version switcher expects semver compliant versions. My project doesn't always use semver compliant names, which was making the whole thing act funny.

Indeed looking at the sphinx documentation, using release for checking the banner to show makes perfect sense.

glad you agree :)

I assume that many people, like initially myself, believe that release should refer to the last "released" version in contrast to a "development" version.

The meaning of those variables is determined by Sphinx (not by theme authors), and is described in their docs.  Briefly: version is expected (by Sphinx) to be X.Y, and release is expected to be X.Y.Z or possibly X.Y.Zrc1 or X.Y.Zdev0 or similar.  Typically the conf.py (where those vars are defined) is version-controlled along with the repo, so sometimes release will be X.Y.Z and correspond to a "stable" or version of the software and its corresponding "stable" documentation. In between stable releases, the value of release can (and in some cases arguably should) change to X.Y.Zdev0 or X.Y.Zrc1 or similar.  Moreover: neither of those variables as defined in conf.py are necessarily used for version matching with respect to the version switcher JSON.  That is done by html_theme_options["switcher"]["version_match"] which might (but need not!) be set to the same value as version or release.

Now, this last "released" version is what you show as x.y.z (stable) in your version switcher. However, in switcher.json you use the preferred flag to indicate that same version. Wouldn't it make sense to use the same name for both? I would suggest use of stable, as that is what this version should be, while "preferred" is a matter of personal choice.

I am struggling to follow exactly what the suggested change is here.  Is it a change to the guidance in our docs?  Or a change to the key names we use in html_theme_options?  Or a change to how we name the fields in the JSON file?  Or a change to the particular values we specify in the JSON file for our own docs?

Adidtional question, does the preferred flag also initialize a substitution |preferred| to reference that version in the docs?

No it does not. It's a neat idea, but not super easy, because which version is preferred is defined in the .json file.  Sphinx substitutions like |preferred| are typically defined in the .rst documents themselves, in .inc files that are included into some/all of the rST documents, or as part of the rst_prolog variable in conf.py.  Substitutions |version| and |release| are special cases that are built into Sphinx, which creates them automatically from the corresponding python variables of the same name.  To do the same thing for preferred for a single project, you would need to add code to your conf.py that:

parses the JSON file given in `html_theme_options["switcher"]["json_url"]
finds the preferred flag on one of the items in the JSON
finds the corresponding version attribute of that item
adds something like f".. |preferred| {preferred_version}\n" to the rst_prolog variable.

it's probably also possible to do something similar in the theme's __init__ file but there the process is less clear to me off the top of my head.

The meaning of those variables is determined by Sphinx (not by theme authors) [...]

I believe this is exactly the point, where the confusion of many users starts.

Correct me if I'm wrong, but I think this means that the most we could do here is "make our own docs a bit clearer".  I'm happy to try to do that / review other's PRs that do so. We do already link to the Sphinx definitions in the switcher-version-match section but maybe we should also do so in the warning banner section?

Moreover: neither of those variables as defined in conf.py are necessarily used for version matching with respect to the version switcher JSON. That is done by html_theme_options["switcher"]["version_match"] which might (but need not!) be set to the same value as version or release.

I understand this, but as mentioned above release is used for determining whether and which banner to show, and I believe that's where many people are confused (see above).

Ah, point taken --- I had lost track of the fact that this was about the warning banner too and not just the version switcher. So I guess the warning banner section needs to make clear that it is the release variable that is used for the warning banner's version matching.

I am struggling to follow exactly what the suggested change is here. [...]

Here I intended to suggest to change the key name in the JSON file to "stable".

I'm not sure I agree with this proposal. "preferred" is more generic, which I think is more accomodating / less confusing for certain cases. In particular, projects that maintain multiple "stable" versions (think of the era of python 2.x and 3.x both being supported, for example), or cases where the developers want users to always be reading the "dev" version of the docs (I've encountered this at least once, but I forget where).
I think I can envision now some concrete improvements to the docs. A couple are fairly straightforward and mentioned above:

link to Sphinx definitions of "stable" and "release" from the warning-banner section
add to the warning-banner section the fact that "release" is what is used for checking against

Additionally, I think it's probably worthwhile to add some background/explanation about why it works this way. Namely:

"version" and "release" are both available at build time (in Python/Jinja code), but
only "release" is available at page load time (sphinx adds "release" as DOCUMENTATION_OPTIONS.VERSION variable available through javascript, but does not add "version" in the same way)

note the naming ambiguity in the prior bullet: what is called "release" in conf.py is called "VERSION" in the (sphinx-provided) JS variable. Maybe we should prominently alert users to that fact? Ideally most won't need to know, but those who go digging might have been saved a lot of time if they'd known that up front.

defining the preferred version in the JSON has an important benefit: you can update a couple lines of that JSON file, and the warning banners on old versions of the docs will change without requiring you to re-run sphinx-build for those old doc versions. The upshot is that the version comparison must happen at page-load time (in JS). This means that:

Something very close to SemVer is required because the comparison relies on an existing Node module for doing version string comparison (and we don't want to re-invent the wheel to handle a bunch of corner cases)
We are limited to (1) what is in the versions JSON and (2) what Sphinx or the theme makes available to JS via the DOCUMENTATION_OPTIONS object. In theory we could define a new var like DOCUMENTATION_OPTIONS.WARNING_BANNER_COMPARISON_VERSION that users could explicitly set in conf.py --- but I'm struggling to imagine the case where users would need to define that as anything other than release (assuming they know that release is what is used, and their switcher JSON file entries should likewise use release-like version strings... in the "version" field of each entry.

That last bullet reveals another non-docs thing we could do that might (?) make things easier: change the JSON field name from version to release --- at least then it would be clearer (?) that the release field in JSON is compared to release in conf.py (via the intermediary of DOCUMENTATION_OPTIONS.VERSION) when deciding if this page warrants a warning banner or not. But, as you've pointed out @FranzRoters, people's prior assumptions about what "release" means is one source of interference here, so I'm not sure that doubling down on the use of that term (by changing the JSON field name to release) will actually be an improvement. (not to mention the code churn needed while everyone updates their JSON files).  So I'm leaning pretty strongly toward a docs-only "fix" here.  Curious to hear your thoughts after reading all this.

Indeed I did not think about cases with multiple stable versions.
So, I do agree that improoving the documentation is the best thing to do. As you said, once the users understands how the existing scheme works, he should be able to work with what is there. In case really needed, one can still define additional varibales in conf.py.

Explaining in the documentation that we have to define both the version and release variables would be helpful. Sphinx doesn't list either of those fields as required. You can remove any of the Project Configuration variables from conf.py and still get a "successful" build. It's an example of variable defaults at its best and worst. I don't need to ever set the values, but if downstream tools depend on them, I'll get behavior that I don't expect.
PyData Sphinx Theme introduces functionality tied to variables that, when initialized to their defaults, causes unexpected behavior. Maybe a two prong approach? Update the documentation and add a utility function that validates version and release that issues a warning if they're not set? I'm not super familiar with the inner workings of the Sphinx build process, so I don't know how difficult the latter might be. The documentation update could be as simple as stating that both those variables are required fields in the conf.py for compatibility with this theme.


Battery heater indicator not working?

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
My battery is cold, I can see that no extra juice is coming in, that car is pulling electricity, so battery heating is happening, however the battery heater indicator is not on.
model 3 SR+
Expected Behavior
Battery heater on charging graph should be on.
Steps To Reproduce

have a cold battery (below 10'C)
Start charging on lower power (2kW)
Observe extended charging time, not charge added, yet no battery heater indicator on.

Relevant log output
teslamate_1  | 2021-11-05 11:57:05.309 car_id=1 [info] Start / :online
teslamate_1  | 2021-11-05 11:57:05.327 car_id=1 [info] Connecting ...
teslamate_1  | 2021-11-05 11:57:54.254 car_id=1 [info] Charging detected: -1 kW
teslamate_1  | 2021-11-05 11:57:55.515 car_id=1 [info] Charging detected: -2 kW
teslamate_1  | 2021-11-05 11:57:55.516 car_id=1 [info] Fetch already in progress ...
teslamate_1  | 2021-11-05 11:57:57.004 car_id=1 [info] Charging detected: -1 kW
teslamate_1  | 2021-11-05 11:57:57.004 car_id=1 [info] Fetch already in progress ...
teslamate_1  | 2021-11-05 11:57:59.447 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (299.356 ms)
teslamate_1  | 2021-11-05 11:57:59.461 car_id=1 [info] Charging / SOC: 62% / Home
teslamate_1  | 2021-11-05 11:57:59.461 car_id=1 [info] Disconnecting ...
teslamate_1  | 2021-11-05 12:04:38.366 [info] GET /
teslamate_1  | 2021-11-05 12:04:38.375 [info] Sent 200 in 8ms
teslamate_1  | 2021-11-05 12:06:52.991 [info] GET /
teslamate_1  | 2021-11-05 12:06:52.999 [info] Sent 200 in 7ms

Screenshots

Additional data
No response
Type of installation
Docker
Version
v1.24.2

My 2019 is showing no battery heater as well. What year is yours? From what I understand, the heat comes from running the motor in stall mode to generate heat, so maybe that's why the battery heater is showing zero.

Mine is 2021 SR+.Does model S/X have the heater?
Sent from Yahoo Mail on Android
On Thu, 30 Dec 2021 at 9:48, @.***> wrote:
My 2019 is showing no battery heater as well. What year is yours? From what I understand, the heat comes from running the motor in stall mode to generate heat, so maybe that's why the battery heater is showing zero.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.Message ID: @.***>

Same issue for my 2020 SR +

I think this issue comes from that there are two battery heater indications from the API.
I noticed when i have the car set to preheat at a specific time, it nowadays will always also preheat the battery, indicated with the heat icon next to the battery indication in the app. In this scenario, in Teslamate you also can't see the car is online for preparing the battery, and Teslamate will just indicate it's online and tries to get it to sleep again.
But the api only shows at one place the battery heater is active and that is in the "climate" part of the API.
  "climate_state": {       "battery_heater": false,
But there is also one at Charge_state:
 "charge_state": {       "battery_heater_on": false,
When my battery is being preconditioned only the climate_state one is active on my car.
Tesla Model 3 SR+ 2019
2021.44.30

Tesla Model 3 SR + 2020  v 2<IP_ADDRESS>
Just tested today Battery heater indicated zero.

I wonder if this is somehow specific to Model S and Model X (I'm the original author of this little feature). It works fine on '16 MS75

Probably M3 doesn't have a separate heater per say.
However, when my M3 is preconditioning (for drive), and it's plugged-in, the Tesla App shows the cable as orange. So they know that there is some process that started. Any chances checking which variable triggers this?

I checked the db, there are 3 parameters;
battery_heater
battery_heater_on
battery_heater_no_power
Only "battery_heater" becomes 1 during charging. "batter_heater_on" is always "false".
Could that be the issue?

Model 3 (and probably also Y) obviously use a different parameter, so fixing this would probably by just a simple OR in the SQL query. Or actually into this case-when statement: (case when battery_heater_on then 1 else 0 end) as \"Battery heater\"
https://github.com/adriankumpf/teslamate/commit/d7afc82330f927418e5e9fa2936efa93e2c788ad

I wonder if the SQL should be changes so that is says: (case when battery_heater or battery_heater_on then 1 else 0 end), or maybe (case when battery_heater then 1 else 0 end) would be the universal solution?

Is preconditioning info used for battery heater as well? Can you monitor the preconditioning value during charging?
While driving my M3 - I did now get the preconditioning signal in teslamate, as shown on the screen shot, so that works.


[track-list.lua] Bug Report + Feature Request + Question

If subtitle's filename contains video's filename, this part is trimmed and ignored in the track list; and in the same way if the sub and video filenames are identical, no track name is shown at all. Is this a bug or is it on purpose? If it's the second, what can I do to always show the full track name?
A second keybinding press should hide the list, not reopen it. I'd like to press , for example, Ctrl+s to open the subs list and press it again to hide it. It would be much more intuitive than having to press ESC.
How to avoid showing these generic track names (Sub 11) for tracks with no name? Thus bringing back the old script behavior.

Screenshots for reference:

If subtitle's filename contains video's filename, this part is trimmed and ignored in the track list; and in the same way if the sub and video filenames are identical, no track name is shown at all. Is this a bug or is it on purpose? If it's the second, what can I do to always show the full track name?
How to avoid showing these generic track names (Sub 11) for tracks with no name? Thus bringing back the old script behavior.

You can achieve this by commenting out the following content in the script:
https://github.com/dyphire/mpv-scripts/blob/6e8ba340c6d4c5451084a3d144b5c2a2565308c0/track-list.lua#L134-L137
https://github.com/dyphire/mpv-scripts/blob/6e8ba340c6d4c5451084a3d144b5c2a2565308c0/track-list.lua#L141-L144

A second keybinding press should hide the list, not reopen it. I'd like to press , for example, Ctrl+s to open the subs list and press it again to hide it. It would be much more intuitive than having to press ESC.

No, this is a limitation of how scripts work, not a bug, and cannot be implemented.

You can achieve this by commenting out the following content in the script:

Thanks, it worked. But the comma before the language code remains. I had the impression that it wasn't like that before, but checking the old versions it seems like it always was. Isn't there an easy way to conditionally add the comma only when the track has a name?

You can achieve this by commenting out the following content in the script:

Thanks, it worked. But the comma before the language code remains. I had the impression that it wasn't like that before, but checking the old versions it seems like it always was. Isn't there an easy way to conditionally add the comma only when the track has a name?

This is because when you comment out the code above, the title may be empty, which will not appear in the original code. For this, you also need to modify the following code:
https://github.com/dyphire/mpv-scripts/blob/1596f85ceea069159ed20e9173da614530348511/track-list.lua#L156-L157

A second keybinding press should hide the list, not reopen it. I'd like to press , for example, Ctrl+s to open the subs list and press it again to hide it. It would be much more intuitive than having to press ESC.

Implement it in the latest commit

mplement it in the latest commit

Thanks!


Add finished state before done

Currently we say "done" as soon as the progress is equal to 100, however
we don't wait for the drive to be ejected/unmounted.
This commit introduces a new state, called "Finishing..." which is shown
when the progress is 100, but the drive has not been unmounted.

Tested in OS X.

Tested in Windows.


inputsize dimension runtime error

the inputsize is (channels,H,W),3-D dimension,if the input is 4 dimension ,for instance:
summary(model, (10,1,28,28))
then error comes:
RuntimeError: Expected 4-dimensional input for 4-dimensional weight [10, 1, 5, 5], but got 5-dimensional input of size [2, 10, 1, 28, 28] instead
how to solve this problem?
@sksq96
thank you very much !

For me it worked when I changed x = [torch.rand(2, *in_size).type(dtype) for in_size in input_size] to x = [torch.rand(*in_size).type(dtype) for in_size in input_size] in line 60, but not sure if this is correct

@csital ｉmean the (channel,H,W),just 3 parameter , can i change it to 4 params ,like (10,1,5,5)

@tongpinmo Yes, you can. Just modify the code as @csital said.
Change the line 60 of torchsummary.py to x = [torch.rand(*in_size).type(dtype) for in_size in input_size]. Then your summary(model, (10,1,28,28)) will work.


Viewers: hide the option “Is Grid” from property panel

This issue has been mirrored in Jira: https://reddata.atlassian.net/browse/GROK-16254