Decimal of float values for vertical annotations?

how can we use decimal value for x-axis to represent and a vertical line using annotation.
annotation: {
                    annotations: [{

                        type: 'line',
                        mode: 'vertical',
                        scaleID: 'x-axis-1',
                        value: 4.5,

                        borderColor: 'green',
                        borderWidth: 4,
                        label: {
                            enabled: true,
                            content: 'Test label',

                        }
                    }]
                },

This code does not work and nothing appears.
But for value:4 it works well. Please let me know what  I have to do to make it support decimal values too

Floating point values should work fine with linear scales. See the samples in https://github.com/compwright/chartjs-plugin-draggable for a working example.


Give a warning if rowKey is missing

As it helps with performance, it would be nice to warn if it's missing.

Adding .required to the proptype should be sufficient.

Hi can u explain more on this, facing warning issues

@sourabhlk It depends on your data. If you have some id value, set the key to point to it. There are plenty of examples in the documentation.


[Bug]: Nested tags split in default tag column

Contact Details
No response
What happened?
Attempted to use default tags column in combination with obsidian inline tags. I used a nested hierarchy and the various parent splits were also included in the tag column. I would like to remove these and attempted, without success, use db dv formula. Photo attached.
${db.dataview.query(Table file.tags as taglist),[row.file]}
Any help would be greatly appreciated!

What platform were you using?
Mobile
Version of the plugin
3.5.0
Relevant log output
No response
Are you using the latest version of the plugin in your Obsidian vault?

[X] I have verified that I am on the latest version

Are you check if there is a similar issue?

[X] I have verified that there are not similar issues

RESOLVED: I used linter to move inline tags to properties and the view + filters work as expected


Suggest using gh cache instead of gh actions-cache

Code of Conduct

[X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#managing-caches
What part(s) of the article would you like to see updated?
The article suggests installing the gh-actions-cache extension for the GitHub CLI. However, recent versions of the GitHub CLI have the gh cache extension (https://github.com/cli/cli/pull/7403), which can be used instead installing the extension. Currently, the extension seems a bit out of date (it appears to have trouble with the CLI's new token storage), so it's probably best to use the gh cache subcommand instead of the gh actions-cache extension.
Additional information
No response

Thanks for suggesting this! I think this change sounds like a good idea. We will just want to tell people that they should make sure to have version >= 2.32.0 of the CLI (https://github.com/cli/cli/releases/tag/v2.32.0) installed if they are doing this manually.
You or anyone else is welcome to open a PR with this update.


Frequency Ranges of Cell Phones

➤ Gavin Allcorn commented:
Explanation of two common cell phone frequency ranges: around 800MHz and around 1900MHz
https://www.solidsignal.com/p/?p=2666&d=determine-cell-phone-range-wirelessadvisor.com&mc=07


Remove sqlx_rt::blocking!() and change runtime-actix feature to be an alias of runtime-tokio

Context: https://github.com/launchbadge/sqlx/issues/713#issuecomment-722028297
For SQLite, we need some way to run blocking work on a background thread. Currently, we use some form of spawn_blocking() (from one of tokio, async-std, or actix-threadpool) to open the database handle and then we do the actual work of running sqlite_step() for executing statements on a dedicated background thread.
If we can get rid of the former, then the runtime-actix feature becomes redundant as the runtime-tokio feature will otherwise work just fine with Actix. (tokio::task::spawn_blocking() doesn't work under Actix because it requires the basic single-threaded runtime, thus the existence of actix-threadpool as a substitute.) For backward compatibility I don't see any reason not to just make runtime-actix an alias of runtime-tokio.
I don't think we want to spawn a separate background thread just to open the DB handle as that's a lot of overhead (and we have no way to join a regular thread in an async fashion anyway), so I'm thinking we could use the same background thread to open the handle and return the result via a futures::sync::oneshot channel, and if successful, have it wait for statements to execute.
The relevant code here is in the following two files:

sqlx-core/src/sqlite/connection/establish.rs
sqlx-core/src/sqlite/statement/worker.rs

For SQLite, we need some way to run blocking work on a background thread. Currently, we use some form of spawn_blocking() (from one of tokio, async-std, or actix-threadpool) to open the database handle and then we do the actual work of running sqlite_step() for executing statements on a dedicated background thread.

FWIW sqlx seems to use something closer to block_in_place: at least for tokio my understanding is spawn_blocking should work on a single-threaded scheduler as it would spawn the task on one of the "blocking" threads, leaving the single "core" thread free to run futures normally (at least in tokio the single-threaded scheduler means all async tasks are run on a single thread, or so I understand it).
I've hit this issue when writing tests: by default tokio::test uses the single-threaded scheduler. When slqx/sqlite is involved, I have to opt into the threaded_scheduler or it panics. However spawn_blocking works just fine on the single-threaded scheduler:
use tokio::test;
use sqlx::{query, sqlite::SqlitePool};

#[test]
async fn test_spawn() {
    let t = tokio::task::spawn_blocking(|| {
        1
    });
    assert_eq!(t.await.unwrap(), 1);
}
#[test]
async fn test_sqlite() {
    let p = SqlitePool::connect_lazy("sqlite://:memory:").unwrap();
    query!("CREATE TABLE IF NOT EXISTS foo ( id INTEGER PRIMARY KEY NOT NULL )")
        .execute(&p)
        .await
        .unwrap();
}

results in:
test test_spawn ... ok
test test_sqlite ... FAILED
thread 'test_sqlite' panicked at 'can call blocking only when running on the multi-threaded runtime'

For SQLite, we need some way to run blocking work on a background thread. Currently, we use some form of spawn_blocking() (from one of tokio, async-std, or actix-threadpool) to open the database handle and then we do the actual work of running sqlite_step() for executing statements on a dedicated background thread.

FWIW sqlx seems to use something closer to block_in_place: at least for tokio my understanding is spawn_blocking should work on a single-threaded scheduler as it would spawn the task on one of the "blocking" threads, leaving the single "core" thread free to run futures normally (at least in tokio the single-threaded scheduler means all async tasks are run on a single thread, or so I understand it).
I've hit this issue when writing tests: by default tokio::test uses the single-threaded scheduler. When slqx/sqlite is involved, I have to opt into the threaded_scheduler or it panics. However spawn_blocking works just fine on the single-threaded scheduler:
use tokio::test;
use sqlx::{query, sqlite::SqlitePool};

#[test]
async fn test_spawn() {
    let t = tokio::task::spawn_blocking(|| {
        1
    });
    assert_eq!(t.await.unwrap(), 1);
}
#[test]
async fn test_sqlite() {
    let p = SqlitePool::connect_lazy("sqlite://:memory:").unwrap();
    query!("CREATE TABLE IF NOT EXISTS foo ( id INTEGER PRIMARY KEY NOT NULL )")
        .execute(&p)
        .await
        .unwrap();
}

results in:
test test_spawn ... ok
test test_sqlite ... FAILED
thread 'test_sqlite' panicked at 'can call blocking only when running on the multi-threaded runtime'


There is presently no way of disabling all audio in Chatterino.

Checklist

[X] I'm reporting a problem with Chatterino
[X] I've verified that I'm running the most recent nightly build or stable release
[X] I've looked for my problem on the wiki
[X] I've searched the issues and pull requests for similar looking reports

Describe your issue
When Chatterino is started, it immediately opens up whatever available audio device (in my case PulseAudio over PipeWire) and will continue to have this open despite having every single sound notification turned off.
You can use "Terminate Playback" in pavucontrol to kill this audio client connection with no ill-effect on Chatterino even if some sort of notification occurs during usage. This not only does not keep the audio device needlessly open but will also reduce Chatterino's overall CPU usage even further. Having audio open all the time even if one disables all sound events is probably the reason why #4613 is preventing proper system idle.
But, this is not a very ideal thing to just boot Chatterino off of the audio server. It should be possible to just launch Chatterino without any audio support whatsoever.
"miniaudio" has a ma_backend_null backend that could be selected if the "Settings" menu allowed selecting any backends manually, but if the end-user does not want any sort of audio handling whatsoever in Chatterino it shouldn't initialize any audio whatsoever in the entire process when launched.
Screenshots
No response
OS and Chatterino Version
Chatterino 2.4.4 (commit e7281b03) built with Qt 5.15.7 Running on Void Linux, kernel: 6.1.44_1

Having the audio device open as soon as the application is started has seemed like the preference for most users since it allows you to modify its volume & output device without having to do it as a sound effect plays.
I would still like that behaviour to be default, but I could see a few settings change how the sound controller works solve most of these options.
Would these three behaviour types solve all use cases you could think of?

Open sound device at startup (Current behaviour, opens the sound device, and doesn't close it)
Open & close sound device on-demand (Opens the sound device when a sound effect is played, and close it again after no sound has been played for a while)
Disabled (Never open a sound device, skip any incoming requests to play sound notifications)

Not sure what the setting name would be, maybe "Sound playback behaviour"?

Having the audio device open as soon as the application is started has seemed like the preference for most users since it allows you to modify its volume & output device without having to do it as a sound effect plays. I would still like that behaviour to be default, but I could see a few settings change how the sound controller works solve most of these options.
Would these three behaviour types solve all use cases you could think of?
1. Open sound device at startup (Current behaviour, opens the sound device, and doesn't close it)

2. Open & close sound device on-demand (Opens the sound device when a sound effect is played, and close it again after no sound has been played for a while)

3. Disabled (Never open a sound device, skip any incoming requests to play sound notifications)

Not sure what the setting name would be, maybe "Sound playback behaviour"?

The second behavior type listed is more in line with how most programs I've used behave, especially web browsers. They don't see any sound playback activity after a period of time and will close the related audio clients as a result of idleness.
This is especially true for sound servers on Linux like PulseAudio and PipeWire, if there's no sound playback occurring, then after a few seconds it'll just close the handle on the audio hardware and allow proper system idle without needlessly feeding silence to the sound device in question.
The only issue I can see with the behavior listed in option two, is latency/overhead as a result of having to open the sound handle again once something happens, which is why I can sort of understand why Chatterino presently just starts up with audio constantly being driven to avoid that sort of hiccup.
The third behavior is currently something I'm specifically wishing for since I never really have audible notifications in anything whatsoever in the first place.

Chatterino 2.5.0 introduced the ability to set the "Sound backend" to Null, which closed out #4978. Does it not address this issue too?

@ashugg Yep! It does. Thank you!


Fix the ima_sign_verification_keys initial datatype

…ings
The variable ima_sign_verification_keys is a string, so initialize
it with an empty string rather than an empty list.
Signed-off-by: Stefan Berger<EMAIL_ADDRESS>

Getting better...

@stefanberger the include pattern that works with mypy is:
import sys
if sys.version_info >= (3, 8):
    from typing import Literal
else:
    from typing_extensions import Literal

trying something like this will not work:
try:
    from typing import Literal
except ImportError:
    from typing_extensions import Literal

Docs: https://mypy.readthedocs.io/en/stable/runtime_troubles.html#using-new-additions-to-the-typing-module


Couldn't run Samsungctl.

This error shows up.
samsungctl --host <IP_ADDRESS> key KEY_POWER Traceback (most recent call last):   File "/home/pi/.local/bin/samsungctl", line 11, in <module>     sys.exit(main())   File "/home/pi/.local/lib/python2.7/site-packages/samsungctl/__main__.py", line 92, in main     config = _read_config()   File "/home/pi/.local/lib/python2.7/site-packages/samsungctl/__main__.py", line 37, in _read_config     except FileNotFoundError: NameError: global name 'FileNotFoundError' is not defined
When commented the FileNotfoundError exception
New error popped up
samsungctl --host <IP_ADDRESS> key KEY_POWER
Traceback (most recent call last):
  File "/home/pi/.local/bin/samsungctl", line 11, in <module>
    sys.exit(main())
  File "/home/pi/.local/lib/python2.7/site-packages/samsungctl/__main__.py", line 93, in main
    config = _read_config()
  File "/home/pi/.local/lib/python2.7/site-packages/samsungctl/__main__.py", line 46, in _read_config
    with config_file:
UnboundLocalError: local variable 'config_file' referenced before assignment

PS:I used pip for installation.

Samsungctl requires Python 3.


Issue with k8s.io/docs/setup/

This is a...

[ ] Feature Request
[ ] Bug Report

Problem:
Proposed Solution:
Page to Update:
http://kubernetes.io/...

may be you lose some information? @rameshk82


add web.archive.org to default no-skip URLs list

Original behaviour redirected from Wayback Machine to archived URL; adding web.archive.org/ to no-skip URLs list in extension settings fixes this and lets users stay on the Wayback Machine.
Before:
https://web.archive.org/web/20240425045640/https://en.wikipedia.org/wiki/Cheese

Fixed with:

There have been plenty of discussions around this, I am not maintaining entries for specific sites.

Fair enough, I'll drop it after this, but I do ask you to seriously reconsider.
This is incorrect behaviour for the extension, a false positive, as Wayback Machine is not supposed to redirect. It shows you an old version of an archived page and there is no redirect to skip in the first place. Every single user will have to manually add web.archive.org to the extension's no-skip-urls-list to fix the fundamental purpose of the Wayback Machine which this extension is breaking. As long as Skip Redirect incorrectly throws people off of web.archive.org you will continue to get people raising Issues and Pull Requests for it, I imagine.

Yeah, I know, but the alternative is that people keep coming with rules for all kinds of websites that I can't and don't want to look into.


YAML file Read issue - How to write YAML file?

Local
Bobcat version: 1.3.
Bobcat modules used:

bb-aem-touch-ui

Browser + version: Chrome Latest

Hi @discovermoi,
please provide full information next time (steps to reproduce, stacktraces, etc.).
From what I see, your YAML is not valid:

you have:

HL:
  HEADER:
    - type:: SELECT
       label: Text Position
       value: Centre

       type: TEXTFIELD
       label: Page Header
       value: test test test

it should be:

HL:
  HEADER:
    - type:: SELECT
       label: Text Position
       value: Centre

    -  type: TEXTFIELD
       label: Page Header
       value: test test test

Hi, Please/kindly check for yourself whether there is any note-able difference between the above two. I am not sure what was the intent to give the above answer. Anyways my apologies for not raising the issue in the intended format.

The intent of my previous comment was, as always, to help with an issue.
I tweaked slightly the formatting, so it should be more readable: notice the missing hyphen in the first example. The content of a tab (HEADER) is supposed to be a list and each item must start with a hyphen. Another potential issue might be formatting - you must use spaces instead of tabs.
Again, I'm only guessing here based on the provided information.

Michal ,
This sounds like the much needed clue - “ spaces instead of tabs”. I will try this.
Appreciation: today I saw the drag and drop feature of IMAGE dialog field. It is amazing. This project helps me in essential learning and unlearning of programming. Highly glad to have come across this.
Best,
Muthukumarlaxman Ekappan
+61 4 1683 2627

From: Michał Krzyżanowski<EMAIL_ADDRESS>Sent: Friday, June 1, 2018 10:04:31 PM
To: Cognifide/bobcat
Cc: EM; Mention
Subject: Re: [Cognifide/bobcat] YAML file Read issue - How to write YAML file? (#241)
The intent of my previous comment was, as always, to help with an issue.
I tweaked slightly the formatting, so it should be more readable: notice the missing hyphen in the first example. The content of a tab (HEADER) is supposed to be a list and each item must start with a hyphen. Another potential issue might be formatting - you must use spaces instead of tabs.
Again, I'm only guessing here based on the provided information.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Cognifide/bobcat/issues/241#issuecomment-393866762, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AZR0g40NX7YOryASiF6tYvFeo61H96J3ks5t4TTXgaJpZM4TwwEQ.

PROBLEM.docx
@mkrzyzanowski - Help needed - The "data" variable of type Component Configs is null even though the config file is read. Not sure what type of stack trace are u expecting. Please let me know in which particular step should I get the stack trace for if the info in word is not sufficient.

@mkrzyzanowski - Structural view of YAML file.

Even after this, if you need steps to reproduce it, Then I must use some Geometrixx Page so that I can expose it.

Hi @discovermoi,
thanks for the info. It seems that for some reason, we are forcing users to name their configuration as lower-cased, since we are reading it with componentConfigs.getConfigs(componentName).get(configName.toLowerCase()) - notice the configName.toLowerCase() part. If you rename your configuration in YAML from PT to pt, all should be fine. Of course such behavior is not documented anywhere, seems like an oversight during TouchUI module release.

My Bad. that is cool.. it is working. Not sure how did I miss guessing this nuance... Apologies.
With regards to "documentation", I am willing to and I can surely help in contributing towards it.
Best,
MuthuKumar R Ekappan
+61 4 1683 2627

From: Michał Krzyżanowski<EMAIL_ADDRESS>Sent: Tuesday, June 5, 2018 1:41 AM
To: Cognifide/bobcat
Cc: EM; Mention
Subject: Re: [Cognifide/bobcat] YAML file Read issue - How to write YAML file? (#241)
Hi @discovermoihttps://github.com/discovermoi,
thanks for the info. It seems that for some reason, we are forcing users to name their configuration as lower-cased, since we are reading it with componentConfigs.getConfigs(componentName).get(configName.toLowerCase()) - notice the configName.toLowerCase() part. If you rename your configuration in YAML from PT to pt, all should be fine. Of course such behavior is not documented anywhere, seems like an oversight during TouchUI module release.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Cognifide/bobcat/issues/241#issuecomment-394411498, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AZR0g_UeGqmpVUGMO1R_Pe1tjDewxyEdks5t5VwjgaJpZM4TwwEQ.

Resolved


Does decorate also works for single function?

Just an internal question, as title says. I saw that it works for interfaces (or how const something = {...} called?), but seems it not work for single function, e.g
function asd() {...}
decorate(asd, cache);

decorators can't be applied to single functions (only for class methods/properties) so it will be great to get kinda hack without deps.

You are correct, you can't decorate a top level function.
You could achieve a similar result by:
function foo() {
    return 1;
}

function decorate(target) {
    const impl = globalThis[target];
    globalThis[target] = function () {
        return impl() + 1;
    }
}

decorate("foo");

Now im dealing with applying real decorator to it. My ts knowledge is bad and i didnt found anything in google. For example your lazy, how i can apply it to single function? I did workaround for my cache

but it requires separate functions. i know that its kinda offtop but any idea?