chime_tts.say does not obey volume_level setting

System Health details
System Information

version
core-2024.12.2

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.13.0

os_name
Linux

os_version
6.6.51-haos-raspi

arch
aarch64

timezone
Europe/Berlin

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

HACS Data
ok

GitHub API Calls Remaining
4993

Installed Version
2.0.1

Stage
running

Available Repositories
1550

Downloaded Repositories
72

Home Assistant Cloud

logged_in
true

subscription_expiration
22. März 2025 um 01:00

relayer_connected
true

relayer_region
eu-central-1

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
false

cloud_ice_servers_enabled
true

remote_server
eu-central-1-14.ui.nabu.casa

certificate_status
ready

instance_id
123d2550cfd34e908cf5a8889e888019

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 14.0

update_channel
stable

supervisor_version
supervisor-2024.11.4

agent_version
1.6.0

docker_version
27.2.0

disk_total
439.4 GB

disk_used
194.2 GB

healthy
true

supported
true

host_connectivity
true

supervisor_connectivity
true

ntp_synchronized
true

virtualization

board
rpi4-64

supervisor_api
ok

version_api
ok

installed_addons
Advanced SSH & Web Terminal (19.0.0), AppDaemon (0.16.7), File editor (5.8.0), Frigate (Full Access) (0.14.1), Mosquitto broker (6.4.1), Piper (1.5.2), SQLite Web (4.3.0), Samba Backup (5.2.0), Samba share (12.3.2), deCONZ (7.0.0), openWakeWord (1.10.0), porcupine1 (1.2.0), RaspberryMatic CCU (<IP_ADDRESS>41122)

Dashboards

dashboards
2

resources
47

views
28

mode
storage

Recorder

oldest_recorder_run
7. Dezember 2024 um 21:55

current_recorder_run
12. Dezember 2024 um 12:47

estimated_db_size
306.19 MiB

database_engine
sqlite

database_version
3.45.3

Checklist

[X] I have enabled debug logging for my installation.
[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 currently previous issues..

Describe the issue
chime_tts.say disregards volume_level setting. It always produces the same volume.
Note: I use a set of Sonos players.
Reproduction steps

Use following code:

action: chime_tts.say
data:
  tts_platform: tts.piper
  message: Test Test Test
  volume_level: 0
target:
  entity_id: media_player.myplayer

Use different values for volume_level from 0 to 1 and / or change your speaker's volume.
Notice there is no difference in volumes as chime_tts.say always plays at speaker's volume.

Debug logs
n/a

Diagnostics dump
No response

Hi @macbih, sorry you've been having issues.
Can you please enable debug logging and provide me with the debug logs so that I might better understand what might be the issue?

Sure! I enabled all the necessary settings and can see the chime_tts logs but unfortunately I am too dumb to copy & paste or download it. Everytime I get the full logs of everything...
So I try to copy one part after another here:
2024-12-13 17:31:03.887 DEBUG (MainThread) [custom_components.chime_tts]     * cache = False
2024-12-13 17:31:03.887 DEBUG (MainThread) [custom_components.chime_tts]     * language = None
2024-12-13 17:31:03.889 DEBUG (MainThread) [custom_components.chime_tts]     * options = {}
2024-12-13 17:31:04.658 DEBUG (MainThread) [custom_components.chime_tts]    ...TTS audio generated in 770.0ms
2024-12-13 17:31:04.658 DEBUG (MainThread) [custom_components.chime_tts]  - Saving mp3 file to local folder: /media/sounds/temp/chime_tts/...
2024-12-13 17:31:04.926 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] File saved to path: /media/sounds/temp/chime_tts/i9ikf70e.mp3
2024-12-13 17:31:05.262 DEBUG (MainThread) [custom_components.chime_tts]  - Chime TTS audio generated:
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts]    * audio_duration = 1.187
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts]    * local_path = "/media/sounds/temp/chime_tts/i9ikf70e.mp3"
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts]    * public_path = None
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts]    * media_content_id = "media-source://media_source/local/sounds/temp/chime_tts/i9ikf70e.mp3"
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭────────────────────╮
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ Chime TTS playback │
2024-12-13 17:31:05.263 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰────────────────────╯
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]    1 Sonos media player detected:
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]      - media_player.michael
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]    Calling media_player.play_media with data:
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]      - entity_id: ['media_player.michael']
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]      - announce: False
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_type: music
2024-12-13 17:31:05.264 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_id: media-source://media_source/local/sounds/temp/chime_tts/i9ikf70e.mp3
2024-12-13 17:31:05.267 DEBUG (MainThread) [custom_components.chime_tts]  - Waiting 1.187s for audio playback to complete...
2024-12-13 17:31:06.457 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]  - Waiting until 1 media_player isn't playing...
2024-12-13 17:31:06.875 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]    ✔ media_player.michael
2024-12-13 17:31:06.875 DEBUG (MainThread) [custom_components.chime_tts] Removing temporary file:
2024-12-13 17:31:06.878 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] Deleting file /media/sounds/temp/chime_tts/i9ikf70e.mp3
2024-12-13 17:31:06.878 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭──────────────────────────────────────────╮
2024-12-13 17:31:06.879 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │──── Chime TTS Say Completed in 3.0 s ────│
2024-12-13 17:31:06.879 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰──────────────────────────────────────────╯
2024-12-13 17:35:39.943 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╔══════════════════════════════════════╗
2024-12-13 17:35:39.943 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ║ Chime TTS Say Called. Version v1.1.5 ║
2024-12-13 17:35:39.944 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╚══════════════════════════════════════╝
2024-12-13 17:35:39.944 DEBUG (MainThread) [custom_components.chime_tts.queue_manager] Adding service call to queue
2024-12-13 17:35:39.946 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭────────────────────╮
2024-12-13 17:35:39.946 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ General Parameters │
2024-12-13 17:35:39.946 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰────────────────────╯
2024-12-13 17:35:39.946 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * entity_ids = ['media_player.michael']
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * cache = False
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * offset = 450.0
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * final_delay = 0.0
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * message = Test Test Test
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_platform = tts.piper
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_speed = 100.0
2024-12-13 17:35:39.947 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_pitch = 0
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * announce = False
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * fade_audio = False
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * volume_level = -1
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * join_players = False
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * unjoin_players = False
2024-12-13 17:35:39.948 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * media_players_array:
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]    - 0: entity_id: media_player.michael
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      platform: sonos
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      initial volume: 0.2
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      target volume: -1.0
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      now playing: False
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      join supported: True
2024-12-13 17:35:39.949 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      announce supported: True
2024-12-13 17:35:39.950 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭─────────────────╮
2024-12-13 17:35:39.950 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ Preparing Audio │
2024-12-13 17:35:39.950 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰─────────────────╯
2024-12-13 17:35:39.953 DEBUG (MainThread) [custom_components.chime_tts]  - Generating new TTS audio with parameters:
2024-12-13 17:35:39.954 DEBUG (MainThread) [custom_components.chime_tts]     * tts_platform = 'tts.piper'
2024-12-13 17:35:39.954 DEBUG (MainThread) [custom_components.chime_tts]     * message = 'Test Test Test'
2024-12-13 17:35:39.954 DEBUG (MainThread) [custom_components.chime_tts]     * cache = False
2024-12-13 17:35:39.954 DEBUG (MainThread) [custom_components.chime_tts]     * language = None
2024-12-13 17:35:39.955 DEBUG (MainThread) [custom_components.chime_tts]     * options = {}
2024-12-13 17:35:46.943 DEBUG (MainThread) [custom_components.chime_tts]    ...TTS audio generated in 6.99s
2024-12-13 17:35:46.944 DEBUG (MainThread) [custom_components.chime_tts]  - Saving mp3 file to local folder: /media/sounds/temp/chime_tts/...
2024-12-13 17:35:47.344 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] File saved to path: /media/sounds/temp/chime_tts/ejozq89t.mp3
2024-12-13 17:35:47.664 DEBUG (MainThread) [custom_components.chime_tts]  - Chime TTS audio generated:
2024-12-13 17:35:47.664 DEBUG (MainThread) [custom_components.chime_tts]    * audio_duration = 1.187
2024-12-13 17:35:47.664 DEBUG (MainThread) [custom_components.chime_tts]    * local_path = "/media/sounds/temp/chime_tts/ejozq89t.mp3"
2024-12-13 17:35:47.664 DEBUG (MainThread) [custom_components.chime_tts]    * public_path = None
2024-12-13 17:35:47.664 DEBUG (MainThread) [custom_components.chime_tts]    * media_content_id = "media-source://media_source/local/sounds/temp/chime_tts/ejozq89t.mp3"
2024-12-13 17:35:47.665 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭────────────────────╮
2024-12-13 17:35:47.665 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ Chime TTS playback │
2024-12-13 17:35:47.665 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰────────────────────╯
2024-12-13 17:35:47.665 DEBUG (MainThread) [custom_components.chime_tts]    1 Sonos media player detected:
2024-12-13 17:35:47.665 DEBUG (MainThread) [custom_components.chime_tts]      - media_player.michael
2024-12-13 17:35:47.666 DEBUG (MainThread) [custom_components.chime_tts]    Calling media_player.play_media with data:
2024-12-13 17:35:47.666 DEBUG (MainThread) [custom_components.chime_tts]      - entity_id: ['media_player.michael']
2024-12-13 17:35:47.666 DEBUG (MainThread) [custom_components.chime_tts]      - announce: False
2024-12-13 17:35:47.666 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_type: music
2024-12-13 17:35:47.666 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_id: media-source://media_source/local/sounds/temp/chime_tts/ejozq89t.mp3
2024-12-13 17:35:47.668 DEBUG (MainThread) [custom_components.chime_tts]  - Waiting 1.187s for audio playback to complete...
2024-12-13 17:35:48.859 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]  - Waiting until 1 media_player isn't playing...
2024-12-13 17:35:49.282 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]    ✔ media_player.michael
2024-12-13 17:35:49.283 DEBUG (MainThread) [custom_components.chime_tts] Removing temporary file:
2024-12-13 17:35:49.284 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] Deleting file /media/sounds/temp/chime_tts/ejozq89t.mp3
2024-12-13 17:35:49.284 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭───────────────────────────────────────────╮
2024-12-13 17:35:49.286 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │──── Chime TTS Say Completed in 9.34 s ────│
2024-12-13 17:35:49.286 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰───────────────────────────────────────────╯

Thanks for the debug log messages. Can you please try again and set the volume_level parameter? Eg:
action: chime_tts.say
data:
  tts_platform: tts.piper
  message: This is a test
  volume_level: 0.75
  chime_path: bells
target:
  entity_id: media_player.michael

Thanks. I don’t see anything wrong in the logs and I know that other Sonos users are able to control the volume this way - so this doesn’t seem like a Chime TTS issue but rather a Sonos issue.
Can you please check if you can call the Home Assistantmedia_player.play_media action to your Sonos speakers with the volume parameter? If not, it would appear you cannot adjust the volume on your Sonos speakers. I suggest you review the Home Assistant forums as perhaps other users have reported this issue.

so this doesn’t seem like a Chime TTS issue but rather a Sonos issue.

In the meantime, I ran the Sonos App and forced a search for a system update. There was one and I applied it.

Can you please check if you can call the Home Assistant media_player.play_media action to your Sonos speakers with the volume parameter?

Then I checked media_player.play_media action with the volume parameter and it worked perfectly! So I went back to square one and re-checked the initial chime_tts.say code from above. And - WTH? - it works now! It regards the volume_level setting as expected!
So you have put me on the right track! Thank you very much for your patience and your support!  🙏

That’s great, I’m happy it all worked out 😀

May I ask an additional question, please? In case this is inappropriate I would open another issue but I believe it belongs to the actual issue although I closed it already.
I would expect
action: chime_tts.say
data:
  tts_platform: tts.piper
  message: Test Test Test
  volume_level: 0.01
target:
  entity_id: media_player.myplayer

to sound almost unhearable but is it not. While I am able to set higher volumes with noticable acoustic differences, the lower (and almost zero) volumes make no difference.
What I am trying to achieve is some kind of "night mode" in a script so that any announcements will be damped:
    sequence:

      - variables:
          volume: "{{ sonos_volume | default(0.3) if is_state('binary_sensor.ha_nightmode', 'off') else 0.1 }}"

      - action: chime_tts.say
        target:
          entity_id: '{{ sonos_entity }}'
        data:
          tts_platform: tts.piper
          language: de
          announce: true
          volume_level: "{{ volume }}"
          message: '{{ sonos_message }}'

Unfortunately, the volume does not seem to be lowered although the message variable gets the right value (0.1).

I am a little confused, I thought you reported that the issue was resolved? Are you saying you can't hear a difference in volume when setting volume_level to 0.1 or 0.3?
I think this issue is again related to Sonos specifically. You can try to use the audio_conversion property to change the volume level of the actual audio file generated by Chime TTS, eg:
action: chime_tts.say
target:
  entity_id:
    - media_player.kitchen
data:
  chime_path: bells
  message: Audio at 30% volume
  tts_platform: google_translate
  tld: com.au
  audio_conversion: Volume 30%

I am a little confused, I thought you reported that the issue was resolved?

Sorry for the confusion! In fact, I have only tested some higher values but not very low values including the edge case of 0.0.

audio_conversion: Volume 30%

I tried that now. There seems to be a difference between both approaches:

audio_conversion seems to act relatively to the current volume of the speaker
volume_level seems to act relatively to the maximum volume of the speaker

That means:

audio_conversion: Volume 0% will lower the volume of the speaker for the announcement but no chime and no message can be heard (as expected)
volume_level: 0.0 won't do anything. There seems to be a minimum volume that will applied to the speaker.

I think this issue is again related to Sonos specifically.

Maybe. While I do not understand why volume_level: 0.0 does not work, I will go for audio_conversion: Volume 0% as a workaround.
Thanks again for your thoughts!

Same issue here. The volume level parameter has no effect on the media player entity volume.
I'm on:
Core 2024.12.5
Chime TTS v1.2.1
action: chime_tts.say
data:
  tts_platform: tts.piper
  message: tts test
  volume_level: 1.0
target:
  entity_id: media_player.sonos

2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╔══════════════════════════════════════╗
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ║ Chime TTS Say Called. Version v1.2.1 ║
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╚══════════════════════════════════════╝
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.queue_manager] Adding service call to queue
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭────────────────────╮
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ General Parameters │
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰────────────────────╯
2024-12-22 16:11:09.372 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * entity_ids = ['media_player.sonos']
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * cache = False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * offset = 450.0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * crossfade = 0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * final_delay = 0.0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * message = tts test
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_platform = tts.piper
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_speed = 100.0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * tts_pitch = 0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * announce = False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * fade_audio = False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * volume_level = {'media_player.sonos': 1}
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * join_players = False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * unjoin_players = False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]  * media_players_array:
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]    - 0: entity_id: media_player.sonos
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      platform: sonos
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      initial volume: 0.39
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      target volume: 1.0
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      now playing: False
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      join supported: True
2024-12-22 16:11:09.373 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers]      announce supported: True
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭─────────────────╮
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ Preparing Audio │
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰─────────────────╯
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]  - Generating new TTS audio with parameters:
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]     * tts_platform = 'tts.piper'
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]     * message = 'tts test'
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]     * cache = False
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]     * language = None
2024-12-22 16:11:09.374 DEBUG (MainThread) [custom_components.chime_tts]     * options = {}
2024-12-22 16:11:09.653 DEBUG (MainThread) [custom_components.chime_tts]    ...TTS audio generated in 280.0ms
2024-12-22 16:11:09.653 DEBUG (MainThread) [custom_components.chime_tts]  - Saving mp3 file to local folder: /media/sounds/temp/chime_tts/...
2024-12-22 16:11:09.713 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] File saved to path: /media/sounds/temp/chime_tts/f21e929ff603273d0de417415f8495ec.mp3
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]  - Chime TTS audio generated:
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    * audio_duration = 1.14
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    * local_path = "/media/sounds/temp/chime_tts/f21e929ff603273d0de417415f8495ec.mp3"
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    * public_path = None
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    * media_content_id = "media-source://media_source/local/sounds/temp/chime_tts/f21e929ff603273d0de417415f8495ec.mp3"
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭────────────────────╮
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │ Chime TTS playback │
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰────────────────────╯
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    1 Sonos media player detected:
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - media_player.sonos
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]    Calling media_player.play_media with data:
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - entity_id: ['media_player.sonos']
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - announce: False
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_type: music
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - media_content_id: media-source://media_source/local/sounds/temp/chime_tts/f21e929ff603273d0de417415f8495ec.mp3
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]      - extra: {'volume': 100}
2024-12-22 16:11:09.799 DEBUG (MainThread) [custom_components.chime_tts]  - Waiting 1.14s for audio playback to complete...
2024-12-22 16:11:10.940 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]  - Waiting until 1 media_player isn't playing...
2024-12-22 16:11:11.546 DEBUG (MainThread) [custom_components.chime_tts.helpers.media_player_helper]    ✔ media_player.sonos
2024-12-22 16:11:11.546 DEBUG (MainThread) [custom_components.chime_tts] Removing temporary file:
2024-12-22 16:11:11.546 DEBUG (MainThread) [custom_components.chime_tts.helpers.filesystem] Deleting file /media/sounds/temp/chime_tts/f21e929ff603273d0de417415f8495ec.mp3
2024-12-22 16:11:11.547 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╭───────────────────────────────────────────╮
2024-12-22 16:11:11.547 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] │──── Chime TTS Say Completed in 2.17 s ────│
2024-12-22 16:11:11.547 DEBUG (MainThread) [custom_components.chime_tts.helpers.helpers] ╰───────────────────────────────────────────╯

Can you please check if you can call the Home Assistantmedia_player.play_media action to your Sonos speakers with the volume parameter? If not, it would appear you cannot adjust the volume on your Sonos speakers. I suggest you review the Home Assistant forums as perhaps other users have reported this issue.

Setting the volume parameter as follows works as intended:
data:
  extra:
    volume: 1.0


 always blows away child's value, even if undefined

<dom-module id='view'>
   <child value="{{foo.bar}}">
<dom-module>

This will always set child.value, even if view.foo.bar === undefined
When binding to structured data, parent always propagates binding to child, even if the property is undefined.
repro:
http://output.jsbin.com/xeweza/2/edit?html,output
This is different from simple property binding. Simple property binding will not propagate value unless defined.
This makes a common pattern impossible with structured properties:

parent has a value 'foo'
child should initialize value foo, so parent leaves foo undefined, and lets child initialize it with binding propagation.
parent's writes to foo propagate to child via binding

This works with foo, but not foo.bar
It kills you when trying to use iron-localstorage with structured variables. It'll probably kill any other data-access-layer too.

To consider: do not propagate undefined for 2-way bindings in _distributeConfig

/sub

Was this ever fixed?

Can a placeholder that holds last valid inputs--provided faux validates are added to bindValue subProperties--act as a shim, shady, shadow, truth, or model data set for each individual object? And if so, is there an easy, native way to make the placeholder on the input act as a native data input.  It has been an eon since I coded in a new language, or had anymore input on a code team than on the business side, that said, in the 90s, I recall a placeholder in HTML acting as a default input.  I may be misremembering, but I am relatively certain there was an attribute at one point or another that served this function in native 1.0 HTML inputs.
If so, would such a placeholder solve this problem?

Something like this, plus a bind to the current object keys and values so that the "Mickey" in the below example would be 'bound' to itself in the input via a 'circular' bind.
object value-->defaultValue-->submittedInputValue--objectValue onNullSubmit
Like below, plus the 'circular bind'
http://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_text_defaultvalue3

Is there a plan for this ?

This qualifies as something bordering on crucial.  Is there an action plan on this?  Does anyone know what the heck is causing it?  It's almost like a booby trap.

It seems that the original JSBin has been overwritten later. Is this still an issue in Polymer 2?

I am unable to reproduce this issue with Polymer 2 (http://jsbin.com/lunecugume/edit?html,console,output), thus I am closing it.


Explicit types

Description
Use explicit types instead of primitives.
For example, the function NegativeInt.compareTo(PositiveInt) should return a NegativeInt instead of an Int.
Checklist

[ ] Implement.
[ ] Test.
[ ] Refactor.
[ ] Update Work in progress section in changelog.

Comparison operations should return an Int (restricted by the language).


Lin 673 lineapy.get for MLflow

Description

Implement LineaArtifact.get_value() for artifacts that use MLflow backend.
Implement LineaArtifact.get_metadata() for artifacts.
Implement lineapy.api.delete to delete MLflow artifact record from lineapy db (not touching MLflow artifact side)
Annotate statsmodel and xgboost and add to MLflow integration.
Add RTD docs for MLflow integration

Fixes # (issue)
LIN-669, LIN-673, LIN-675, LIN-676, LIN-690
Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

How Has This Been Tested?

Adding LineaArtifact.get_value and LineaArtifact.get_metadata to existing test.
For lineapy.delete, manually validate the artifact entry has been deleted from node_value, artifact and mlflow_artifact_storage tabels.

To add new docstrings into RTD's API reference page, please run:
cd docs && rm -rf build source/build source/_build source/autogen && SPHINX_APIDOC_OPTIONS=members sphinx-apidoc -d 2 -f -o ./source/autogen ../lineapy/ && make html

This will update docs in lineapy/docs/source/autogen/, which you will need to commit.


Di aws config

This adds the ability to use AWSSDK.Extensions.NETCore.Setup package. This should result in less boilerplate code checking for test/dev environments. We can use the profile or config files to drive the behaviour we want rather than baking it into code.

Once we're decided on a name, this will need rebasing and having the public API analysers added.


can't connect to cockpit

Built a v1.3.0-alpha.3 box and when I try to connect to the url for cockpit I keep getting
Disconnected
Your session has expired. Please log in again.
This happens after I authenticate. Not sure if this is our problems or theirs
Here are the log messages:
NFO: cockpit-ws: logged in user: admin
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
INFO: cockpit-ws: New connection from <IP_ADDRESS> for admin
WARNING: cockpit-bridge: bridge doesn't support payloads of type: stream
MESSAGE: cockpit-protocol: http://localhost:8080/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:8443/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:6443/api: couldn't connect: Connection refused
WARNING: cockpit-bridge: bridge doesn't support payloads of type: stream
MESSAGE: cockpit-protocol: http://localhost:8080/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:8443/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:6443/api: couldn't connect: Connection refused
WARNING: cockpit-bridge: bridge doesn't support payloads of type: stream
MESSAGE: cockpit-protocol: http://localhost:8080/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:8443/api: couldn't connect: Connection refused
MESSAGE: cockpit-protocol: https://localhost:6443/api: couldn't connect: Connection refused
INFO: cockpit-ws: WebSocket from <IP_ADDRESS> for admin closed
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
MESSAGE: cockpit-protocol: couldn't read from connection: Error receiving data: Connection reset by peer
INFO: cockpit-ws: admin: timed out
Go to top
Container: openshift-cockpit  Time Range:

Looks like there is a problem in the service since we are not exposing all those ports but then again it is looking to localhost so the service shouldn't matter
name=openshift-cockpit
Type:
ClusterIP
IP:
<IP_ADDRESS>
Session affinity:
None
Routes:
http://cockpit.apps.<IP_ADDRESS>.xip.io
Node Port		Service Port		Target Port
none	→	80/TCP (http)	→	9090

Is there a solution for this? I am experiencing the exact same problem.

This work is no longer maintained in favor of https://github.com/minishift/minishift which is the preferred way to run OpenShift Origin locally.
@malagant what version are you using?


Got TypeError when running VGG example

The error log is below:
TypeError                                 Traceback (most recent call last)
<ipython-input-15-73a1b345b022> in <module>()
----> 1 ig = integrated_gradients(model)

/home/ubuntu/GA/IntegratedGradients-master/IntegratedGradients.py in __init__(self, model, outchannels, verbose)
     73                 gradients = self.model.optimizer.get_gradients(self.model.output[:, c], self.model.input)
     74             if K.backend() == "theano":
---> 75                 gradients = self.model.optimizer.get_gradients(self.model.output[:, c].sum(), self.model.input)
     76
     77             # Build computational graph that computes the tensors given inputs

/home/ubuntu/anaconda3/envs/theano_p27/lib/python2.7/site-packages/keras/optimizers.pyc in get_gradients(self, loss, params)
     88     def get_gradients(self, loss, params):
     89         grads = K.gradients(loss, params)
---> 90         if None in grads:
     91             raise ValueError('An operation has `None` for gradient. '
     92                              'Please make sure that all of your ops have a '

/home/ubuntu/anaconda3/envs/theano_p27/lib/python2.7/site-packages/theano/tensor/var.pyc in __iter__(self)
    630         except TypeError:
    631             # This prevents accidental iteration via builtin.sum(self)
--> 632             raise TypeError(('TensorType does not support iteration. '
    633                              'Maybe you are using builtin.sum instead of '
    634                              'theano.tensor.sum? (Maybe .max?)'))

TypeError: TensorType does not support iteration. Maybe you are using builtin.sum instead of theano.tensor.sum? (Maybe .max?)

it only wrong with theano backend,
it works well with tensorflow backend


How would I make voice commands with this

I want to make voice commands using this but I have no idea how

I found out how to create voice commands, just get the message that the bot thought you said and make that into an if statement kinda like
client.on("speech", (msg) => {
  console.log(msg.content)
  const scr = client.channels.cache.find(channel => channel.id === "932082099836555345")
  scr.send(msg.content)
  if (msg.content === "!leave" || msg.content === "exclamation mark live" || msg.content === "Imma head out") {
    const voice = require('@discordjs/voice');
    voice.getVoiceConnection(`895951251911630870`).disconnect();
  }
});

Basically it, the first bit just sends the content to a channel, as well as the console and then the second if statment checks to see if the content included those words, for me when i said !leave it came up as exclamation mark live and once it gets those it just disconnects the bot from the channel, oh and i also made the bot joining the channel into a command which for me is !listen


Fix issues with request history components

This pull request fixes several issues related to the request history components. It includes the following commits:

Remove unused Vue components

Update models and serializers in afb API

Add TypeScript interfaces for Django models

Update RequestList to display FoodRequest results

Standardize user identifier field naming

Add missing fields to FoodRequest serializer

Simplify request details and integrate API data

Misc config updates

These changes address the issues mentioned in the pull request and improve the functionality and consistency of the request history components.

/add_docs

/test RequestDetails.vue


Hidden is supported on ie9

My company uses ie9 as our company standard browser and "hidden" does work as expected on ie9.  We are running
Version 9.0.8112
Update Version 9.0.38

Not in my tests. See for example http://codepen.io/Fyrd/pen/dYpobx
If you have a specific testcase you can show me where it's working, please share.

Thanks for your consideration.  I see the javascript that runs is making:
 This should be hidden
element when it renders.  It should be
This should be hidden
It might be a ie9 DOM/JS interaction issue, but the straight hidden attribute does work.
I will create a full stand alone web page and send the link that shows hidden attribute working as expected.

rats, it erased all my html snippets, forgot about git hub and markdown.  I'll be back later, but basically the js interaction is creating 'hidden=""' rather than just 'hidden' attribute.


Fix unregister issue

This PR adds a fix for #124. A minimal test case for this issue can be found here.
The fix, taken from @intrasoft-eu's solution, uses mql.currentTarget if it's available:

Whenever an unregister is happening, the debugger throws "undefined not a function", because 'mql' is not a MediaQueryList but a MediaQueryListEvent, which doesn't have the removeListener method, and thus the error is thrown.

More details can be found in the issue thread.

Closed as i fixed independently (didn't want to commit the dist files from here, or wait for response). Thanks for making the PR, really appreciate it!  Thanks for fixing!


Loglevel 2.0

Loglevel is good. It's time to make it fresh. More clearly. More modern.

Remove support for legacy browsers.
Remove support for persistance levels.
Remove noConflict()
Сustomizable levels
Flat flow of plugins (only one extra line in the stacktrace for any number of plugins)
log.getLogger('child') => log('child')
getter/setter log.level
maybe something else...

Implementation loglevel.js
const noop = () => {};
const loggers = {};
const configs = {};
const chain = [];
let levels = ['trace', 'debug', 'info', 'warn', 'error', 'silent'];
let levelsInfo = levels.slice();

class Plugin {
  constructor(name) {
    this.name = name;
  }

  // eslint-disable-next-line class-methods-use-this
  factory() {
    return () => {};
  }
};

// Build the best logging method possible for this env
// Wherever possible we want to bind, not wrap, to preserve stack traces
function defaultFactory(methodValue) {
  /* eslint-disable no-console */
  if (typeof console === 'undefined') return noop;

  const methodName = console[levels[methodValue]] ? levels[methodValue] : 'log';
  if (console[methodName]) return console[methodName].bind(console);

  return noop;
  /* eslint-enable no-console */
}

function pluginsFactory(methodValue, logger) {
  const methods = [];

  chain.forEach((plugin) => {
    const rootConfig = configs[plugin.name][''];
    const loggerConfig = configs[plugin.name][logger.title];
    if (rootConfig || loggerConfig) {
      methods.push(
        plugin.factory(
          methodValue,
          logger,
          Object.assign({}, plugin.defaults, rootConfig, loggerConfig),
        ),
      );
    }
  });

  const native = defaultFactory(methodValue);

  return (...args) => {
    for (let i = 0; i < methods.length; i++) {
      methods[i](args);
    }
    native(...args);
  };
}

let factory = defaultFactory;

function rebuildMethods(logger) {
  for (let i = 0; i < levels.length - 1; i++) {
    logger[levels[i]] = i < logger.level ? noop : factory(i, logger);
  }
}

function removeMethods(logger) {
  for (let i = 0; i < levels.length - 1; i++) {
    delete logger[levels[i]];
  }
}

function Logger(logName, logLevel) {
  const logger = this || {};

  const defineProperty = Object.defineProperty;

  defineProperty(logger, 'title', {
    get() {
      return logName;
    },
  });

  defineProperty(logger, 'level', {
    get() {
      return logLevel;
    },
    set(lvl) {
      let newLevel = lvl;

      if (typeof newLevel === 'string') {
        newLevel = levels.indexOf(newLevel.toLowerCase());
      }

      if (typeof newLevel === 'number' && newLevel >= 0 && newLevel < levels.length) {
        logLevel = newLevel;
        rebuildMethods(logger);
      } else {
        throw new Error(`Invalid level: ${lvl}`);
      }
    },
  });

  defineProperty(logger, 'levels', {
    get() {
      return levelsInfo;
    },
  });

  logger.use = function (plugin, config) {
    // if (
    //  typeof plugin === 'object' &&
    //  typeof plugin.name === 'string' &&
    //  typeof plugin.factory === 'function'
    // ) {
    if (plugin instanceof Plugin) {
      const pluginName = plugin.name;
      if (!configs[pluginName]) {
        // lazy plugging
        configs[pluginName] = {};
        chain.push(plugin);
        factory = pluginsFactory;
      }

      plugin = pluginName;
    }

    if (typeof plugin !== 'string' || !configs[plugin]) {
      throw new Error(`Invalid plugin: ${plugin}`);
    }

    configs[plugin][logName] = config || {};
    rebuildMethods(logger);
  };

  logger.level = logLevel;
  loggers[logName] = logger;

  return logger;
}

function log(name, level) {
  name = name || '';
  if (typeof name !== 'string') {
    throw new TypeError(`Invalid name: ${name}`);
  }

  return loggers[name] || new Logger(name, level || log.level);
}

Logger.call(log, '', 3);

log.Plugin = Plugin;

log.config = (newLevels, newLevel) => {
  Object.keys(loggers).forEach(logger => removeMethods(loggers[logger]));

  levels = newLevels;
  levelsInfo = levels.slice();

  Object.keys(loggers).forEach((logger) => {
    loggers[logger].level = newLevel;
  });
};

export default log;

Example
const log = require('loglevel');

class Prefixer extends log.Plugin {
  constructor() {
    super('prefixer');

    this.defaults = {
      text: 'default prefix',
    };
    this.prevs = {};
  }

  factory(method, logger, config) {
    return (args) => {
      const timestamp = Date.now();
      const prev = this.prevs[logger.title];
      const delta = prev ? timestamp - prev : 0;
      this.prevs[logger.title] = timestamp;
      args.unshift(
        `[+${delta}ms] ${logger.levels[method].toUpperCase()} (${logger.title}) "${config.text}":`,
      );
    };
  }
}

log.level = 'trace';

(function StackTraceTest() {
  log.trace();
}());

const child = log('child');
child.info('child');

const prefixer = new Prefixer();

child.use(prefixer, { text: 'custom prefix:' });

log.info('root');

child.info('child');

let sum = 0;
for (let i = 0; i < 1000000; i++) {
  sum += Math.log(0.1);
}

log.use('prefixer');

log.info('root');

child.info(sum);

log.config(['verbose', 'trace', 'critical', 'silent'], 'trace');

log.critical('critical');

child.verbose('verbose1');

child.level = 'verbose';
child.verbose('verbose2');

(function StackTraceTest() {
  log.trace();
  child.trace();
}());

Output
C:\Users\u36\Dropbox\kutuluk\logler>node ./examples/example
Trace
    at StackTraceTest (C:\Users\u36\Dropbox\kutuluk\logler\examples\example.js:29:7)
    ...
child
root
[+0ms] INFO (child) "custom prefix:": child
[+0ms] INFO () "default prefix": root
[+27ms] INFO (child) "custom prefix:": -2302585.0930085
[+1ms] CRITICAL () "default prefix": critical
[+1ms] VERBOSE (child) "custom prefix:": verbose2
Trace: [+0ms] TRACE () "default prefix":
    at Function.trace (C:\Users\u36\Dropbox\kutuluk\logler\lib\logger.js:105:14)
    at StackTraceTest (C:\Users\u36\Dropbox\kutuluk\logler\examples\example.js:64:7)
    ...
Trace: [+2ms] TRACE (child) "custom prefix:":
    at Logger.trace (C:\Users\u36\Dropbox\kutuluk\logler\lib\logger.js:105:14)
    at StackTraceTest (C:\Users\u36\Dropbox\kutuluk\logler\examples\example.js:65:9)
    ...

If this fits into the development concept of loglevel, I will make a pull request

This is really great.
I've got some specific thoughts below, but generally I'm very keen on this, there's a lot of nice improvements here that we can make to iterate on feedback and improve the UX longterm.
There's a couple of places where I'm not totally sold, but most of this sounds superb. The main thing I'm trying to do is ensure that loglevel continues to work out of the box for as many people as possible, even in awkward environments, not just for people keeping up to date with the nicest modern stack.
On your list above:

Remove support for legacy browsers.

Open to this, but we should be explicit about what that means. I'd be ok with dropping support for browsers with < 1% web traffic right now though. That still leaves IE 11 (~3% of web traffic in Jan 2018), but rules out the rest of IE, and a lot of the other older browsers. I'm pulling stats from here: http://gs.statcounter.com/browser-version-market-share

Remove support for persistance levels.

I find persistence quite useful. Without it, you can't change the log level used at page startup without rewriting the source of the page itself. I'm open to disabling it by default or something though.
We could disable persistence by default, and create a .persist() method instead, which persists the current level.
In fact, that could even be a plugin actually (add .persist(), load current level on plugin registratoin), maybe that's the right way to go, and we just need to ensure that's practical...

Remove noConflict()

Why? There's definitely (sadly) still a meaningful proportion of web development that happens without proper module systems (42% of devs use browserify/webpack, 10% use RequireJS, and 32% don't do any bundling whatsoever, according to the https://www.sitepoint.com/front-end-tooling-trends-2017, this time last year), and if you're using a global then noConflict can be pretty important. Easy to implement, and doesn't hurt anybody else afaict.
Generally I'm quite keen to ensure loglevel is useful for as many JS developers as possible, so while there's still a contingent using bare JS & it's easy, it'd be nice to support them. It's useful to let you quickly add nice logging to tiny scripts in HTML pages or into sites like jsbin too, with zero setup required.

Сustomizable levels

Oooh, nice fix to a common debate, definitely!
Curious what the API for this looks like though - how do I define a new level, and map it to a console function?

Flat flow of plugins (only one extra line in the stacktrace for any number of plugins)

100%, and we can pull in plugin API improvements en route too

log.getLogger('child') => log('child')

I don't have strong feelings about this. This is shorter, but getLogger feels clearer. Still, if you do then I'm happy to change it.

getter/setter log.level

Nice idea, definitely :+1:

Maybe something else...

Built in Flow & TS type definitions would be nice (personally I'd probably just rewrite the source in TS, but up to you)
Support for some more console methods (like timing and group)
Don't any of that for 2.0.0, just as part of the v2 direction in future.

Speaking of version 2.0, I meant completely abandoning obsolete environments. Backwards compatibility could be saved with the help of the loglevel/legasy submodule. This is a common practice.
But I do not insist, because I understand that loglevel is widely used and breaking back compatibility is undesirable. Therefore, I realized my idea in the form of a package https://github.com/kutuluk/log-n-roll. This is a 900-byte logger with a built-in prefixer. I think this is ideal for modern applications such as SPA and PWA.
But I can say with confidence that all the same thing can be implemented in loglevel. The difference is only in size. So you just need to decide which changes will improve the loglevel and make them.

Awesome work, and ideas I hope this won't grow into YAL (yet another logger).
I'm happy to contribute to any of this, and able to write TS.
One idea about compatibility:
I haven't totally wrapped my head around it, but maybe this is possible:
Have two kind of builds: one for "modern usage" as @kutuluk called it,
but available under loglevel/modern (since it is easy for newer methods to only require/import that part)
and the fully fledged legacy support still being available under loglevel.
I have't looked at the code base so far, but maybe the compatibility can also be added as a plugin?

Implementing the support of browsers from the Stone Age, you risk yourself stuck in the Stone Age. If this is your choice, then I'm not going to challenge it. But I want to live today and look into tomorrow, instead of hanging in yesterday.
My position is very strong - backward compatibility with browsers no lower than IE 11 (ES5). Ensuring compatibility below is not a library task - it's a task for https://github.com/es-shims/es5-shim.

backward compatibility with browsers no lower than IE 11 (ES5)

Yep, that sounds good to me. As in my comment above, I think IE 11 is a good & low bar nowadays, and I'm fine with only publishing a 'modern' build that supports IE11+. That's still very inclusive (IE10 is now down to 0.1% of browser usage), and users who want support back even further than that can just stick with loglevel 1.x, which will keep working fine for all sorts of super old browsers, or look at shimming etc if they really need to. A legacy build would work, but I'd rather just point people back to 1.x and keep ongoing dev simple.
The main legacy bit that I would like to retain is UMD, for developers not using webpack and similar, since the stats seem to suggest that's still a significant percentage of developers. That's a cheap, easy and tiny addition though, and doesn't get involved in the core of the code - we just keep the UMD wrapper & noConflict. We could do that in a separate build if we really wanted to, but publishing etc is all quite a bit simpler if there's just a single copy that works everywhere.

I think IE 11 is a good & low bar nowadays, and I'm fine with only publishing a 'modern' build that supports IE11+.

It sounds delicious. My current implementation https://github.com/kutuluk/log-n-roll is fully operational in IE 11. With the help of https://github.com/developit/microbundle three builds are compiled: UMD (without noConflict), CommonJS and ES6.
My opinion about noConflict(): resolving name conflicts is not a library task, it's a programmer's task. The only thing that is needed from the library is to provide a permanent name, which is occupied in the global scope. One clause in the documentation. Nothing more.
I've already changed my original sketch and now it's almost finished. I propose to take it as a basis, thoroughly think through the API, implement some of the most popular plug-ins (in a simplified form I have already implemented something), test and merge into loglevel under version 2.0 without backwards compatibility. The current version of loglevel is published as loglevel@legacy and maintained separately.

That all sounds great to me. I've opened a v2 branch on this repo, can you PR changes into there? That way we can do a series of PRs to reimplement the core, then update the docs etc, and make various other improvements I'd like around the project, and finally merge & release it all together once it's all ready.
I'm still on the fence about noConflict(). You're right that developers can work around it themselves, but it can be quite awkward, and it's a pretty strong convention. Anyway, we can get started regardless. PR whatever you're happy with to v2 when you're ready, and we can start with that and iterate from there.

I'd second that it'd be nice to see persisting levels disabled by default (The current behaviour is confusing as we use default_level and if a log level is set, we can't override without explicitly enumerating loggers and calling setLevel.
Alternatively, provide a clear method~
 if (window.localStorage) {
      window.localStorage
      const isLogLevel = R.contains('loglevel');
      for (var key in window.localStorage){
        if (isLogLevel(key)) {
          window.localStorage.removeItem(key);
        }
      }
    }

These ideas all sound great, from my end I don't think there's any must haves in the suggested v2 features. But I'm just evaluating the library at this point, so I'm probably missing a lot of context.
My interest is more on being able to add plugins to the log system in order to have flexibility on sending logs to a server, and it looks like the current version supports that with a few plugins already (or we could write our own).
What's the status of v2, doesn't look there's been much activity on that branch ...

@pimterry Do you still have any appetite for someone picking this work up? Last time this came up in January 2023 I did not have the time or energy for it (and it wasn’t clear whether you had time to really shepherd anybody’s work on it either). I might have some time for this later in December or January.
If you are interested, what are the important goals?

You’ve talked in a few places about rewriting in TypeScript, so I assume that’s a strong desire on your part. (It need not be a breaking v2-level change, though.)

I think it’s safe to drop IE (it’s been almost 7 years since the previous discussion on it here, and it’s effectively gone from the rankings), but what criteria do you want to apply for determining minimum support?
I am deeply on-board with maintaining a broad and sometimes old support base (stability and long-term runtime support is one of the things I really appreciate about this library!), although v2 gives us a nice opportunity to use some newer JS features like class syntax, getters/setters, etc.
I think Loglevel already works fine in Bun/Deno/QuickJS, but it would probably be nice to make it official. :)

ESM support has been around for long enough now that I think it is the best way to ship this library by default, but it might be useful to continue shipping a UMD build as well (I think this is fairly self-evident, but recent articles like Julia Evans’s “Importing a frontend Javascript library without a build system”, or the continuing issues around Node.js or Jest support for modules are also good indicators).

Rethinking plugin support seems like a big feature in this discussion already, and it certainly came up the cleanup work I did here a year ago. This would solve #82, #117, and remove the rebuild() function introduced to solve #187.

Rethinking persistence also seems to have come up here and in other places. It seems clear that setLevel() vs. setDefaultLevel() can be a little confusing, too, and the latter mostly exists because of persistence (originally my fault, IIRC).
The right way out of this is probably to make saving the current level its own method and never do it by default (as suggested earlier in this thread). We should probably also just get rid of setDefaultLevel() entirely — without persistence-by-default, it’s just sugar for if (!logger.getPersistedLevel()) logger.setLevel(x), which is really simple. It’s mainly valuable for library authors (as opposed to app authors), and library authors usually shouldn’t be setting their own level anyway.

Rethinking logger hierarchy/relationships.

Loggers take their level from the root logger at creation time, which leads to unpredictable defaults and messy config (I think this was my fault, too). Non-root loggers should either be totally independent of the default logger or maintain a live relationship (if they haven’t had their own level explicitly set, they have the level of their parent, including changing when the parent changes — we talked about this in #191 but decided it would be a breaking change).
We punted on hierarchy deeper than 1 level when first adding multiple logger support and never revisited it. This is mainly a question of inheriting levels and plugins (see above point). v2 is a good to time to implement this if we want it.

Map debug() to console.debug()? (#137)

Configuration via environment variables (#124) and maybe querystring? (Not really breaking changes that need a v2 release)

Are there important things not in that list? Things in that list you have specific ideas about?

Do you still have any appetite for someone picking this work up?

I just had a baby a couple of months ago, so I am quite busy! That said, I can probably help with shepherding things slowly through and I do still think many improvements here would be worthwhile.
Of your list above:

Rewriting the codebase in TypeScript might be nice but isn't critical (although I do find it very useful) but we should certainly publish types.
I too am keen to maintain a very wide support base.

I'd be very happy to add wider runtime support (Bun/Deno/etc) to that.
I'd agree we can drop some older browsers now, but I'm not sure where would be best to set the line. Fancy syntax isn't really the issue (it'd be easy to compile to older JS formats, or even provide multiple bundles for different levels of compat), it was really the weird behaviours of old console globals that was the largest problem, which was mostly an IE6/7/8 issue.
The big question is whether we support IE11 or not - it's now very old, but caniuse suggests it's still ~0.5% of web traffic (highest of the IEs), Microsoft still supports it for long-term paid support customers (https://endoflife.date/internet-explorer), at a global scale 0.5% is not an inmaterial number of people, and jQuery v4 (currently in beta) will be IE11+. Depends how much effort it is really, so I'd suggest we aim for that but just keep an eye out for major problems.
Regardless, I'd be happy to say anything older than IE11 can definitely go for v2, which will simplify things significantly.

ESM support definitely, but yes I'd want to keep a UMD build to provide support for CJS & global usage too at least (I had assumed AMD was dead, but https://www.npmjs.com/package/requirejs still getting 1 million downloads a week suggests not - at least we get this for free with UMD anyway). Nowadays export maps should make it easier to do this cleanly (so modern ESM envs or bundlers don't need to worry about the UMD bundle).
Yes, improving the plugin API would be great. The key problem before was that it was designed as an afterthought - hopefully we can design it up front to do better this time around :smile:.
Agreed on dropping default persistence. Seems like something that could plausibly become a plugin if we started firing a 'level-changed' event or something?
Hierarchy ideas are interesting! I don't immediately know what's best here, but I'm very open to improvements and I can certainly see good arguments for if they haven’t had their own level explicitly set, they have the level of their parent, including changing when the parent changes and multi-level hierarchies alongside that.
Yes, very very happy to finally resolve #137 and use console.debug again now
For env vars/querystring, I think configuration from external sources is something we should think about as a plugin. Seems like a sensible thing to support, but doesn't necessarily seem like something everybody will want or need.

Other thoughts:

We should continue to aim to not break the log stacktraces/source line by default, and make it possible for plugins to do the same wherever possible (which means logic based on bind()ing console methods, and other such tricks). It's not always possible, but it's really useful to have most of the time and a key part of the tradeoff between loglevel vs other logging libraries.
Would be good to keep the library as small & fast as possible (i.e. minimizing the total runtime JS, and especially the cost of logging calls themselves) and keep functionality to just the essentials, moving what we can into plugins. Some things need to be built in (logging itself, levels definition & configuration, the plugin API, the logger hierarchy), but most other things (timestamps, formatting, remote log transports, persistence) could easily be optional additions.
That said, we should be able to include support for more console.* methods (time/timeEnd, group, etc) - this is mostly just implementing them as passthrough to the real API. I'm not sure what the compatibility issues are here, but including some basic fallbacks so you can just call anything everywhere and always get something basic at least (if there are indeed any methods not supported in all our target envs) without any risk of errors is important.
Where possible, I'd like to use tooling etc that's unlikely to go through constant churn in future. Bash scripts and small focused mature libraries instead of fancy task runners & frameworks (this may actually be an argument against typescript). With small long-term-stable libraries like this, tooling churn becomes a bigger overhead and hassle than core development if we're not careful.

We should continue to aim to not break the log stacktraces/source line by default… Would be good to keep the library as small & fast as possible

👍 My feel on the core ideas that make Loglevel what it is and that we don’t want to break are:

Very small and no dependencies — low cost and easy to include in your project.
Broad compatibility/Just Works™ in most environments.
Keeps the stack/callsite info intact by default.
Filters by level.
Multiple, named logger instances.

The big question is whether we support IE11 or not - it's now very old, but caniuse suggests it's still ~0.5% of web traffic (highest of the IEs), Microsoft still supports it for long-term paid support customers

Whoa, I hadn’t realized it was still supported in any form! 😅 FWIW, caniuse is showing 0.37%, but I think that’s out of date — their data comes from statcounter.io, which is showing 0.09% for November 2024 (CSV) (the last date that had 0.37% was January 2022, so my guess here is that caniuse stopped updating IE numbers when general support was discontinued in 2022, and 0.37% was the high mark for that year).
Anyway, I agree that’s not nothing, although it’s trending fast toward an order of magnitude less than 0.5%. Happy to go with whatever you decide here. (Interesting side note: I was hoping to dismiss it entirely by seeing all the usage come from US/Europe, where it probably represents old enterprise apps that aren’t going to upgrade any Loglevel version they might be using, but no, it is coming exclusively from Iran, Turkmenistan, and …Liechtenstein (!), which are not so easily ignorable).

We should certainly publish types. …I'd like to use tooling etc that's unlikely to go through constant churn in future. Bash scripts and small focused mature libraries instead of fancy task runners & frameworks (this may actually be an argument against typescript)

I definitely hear you on wanting to minimize churn from tooling. But I think this is always going to be an issue since the level of compatibility you are shooting for is just way beyond what the JS community as a whole is worried about. This development note on compatibility will probably always be necessary.
In particular, I don’t think we can escape:

Including TypeScript as long as we are publishing types. At the very least, we need some tests of the type definitions, and I don’t know a good way to do that without TypeScript.

A test framework of some sort. I just don’t think it’s worth rolling our own, for so many reasons.

It’s probably possible to replace a lot of the existing Grunt stuff with bash. Otherwise, I’m not sure it’s possible to get more minimal than we are now after #194 and #195.
For types in particular, I’ve maintained packages that build their types from JSDoc comments and ones where the actual source is TypeScript. If this is going to essentially be a rewrite, I would tend towards writing in in TypeScript, but that does tend to add to the dev tooling complexity. So JSDoc comments might be better in that regard. Either way, I would recommend against continuing to hand-roll the type definitions.

it'd be easy to compile to older JS formats, or even provide multiple bundles for different levels of compat

I think we probably want to try and avoid that (at least as much as is reasonably possible), since it drives us right back to this tooling churn issue.

[Persistence] Seems like something that could plausibly become a plugin… For env vars/querystring, I think configuration from external sources is something we should think about as a plugin.

I was thinking we definitely still want built-in support for loading dynamic configuration of some sort — I can understand how that’s not “core,” but it still seems like a pretty basic and common need. If I want to flip on more detailed debugging while investigating a shipping version of a website or app (or filing an issue/support ticket), it’s really nice to be able to just do that without having thought ahead to add an extra plugin or custom code of your own (assuming you are the app’s author; this isn’t an option for you otherwise).
And insofar as the places we’re loading from are writable (e.g. localstorage or cookies and not env vars or querystrings), it would make sense to build in the corresponding write support.
Alternatively, maybe built-in support only includes sources that are non-writable, e.g. env vars or URL querystring/hash? That sidesteps the saving/writing issues.

we should be able to include support for more console.* methods (time/timeEnd, group, etc)

I think there are a lot of open questions here! And there’s already a lot to think about in all the above stuff. Maybe best to leave this to plugins to patch in for now, and it’s something that could be addressed in a later 2.x release?

@pimterry

I just had a baby a couple of months ago, so I am quite busy!

Congratulations!
Love this lil library.
@Mr0grog

It’s probably possible to replace a lot of the existing Grunt stuff with bash.

Be aware that zsh and fish are also popular with some people. Perhaps look into a Makefile (so that you have a single interface that then could adapt to different shells).

Congratulations!

Thanks!

Be aware that zsh and fish are also popular with some people. Perhaps look into a Makefile (so that you have a single interface that then could adapt to different shells).

True - but these would be shell scripts, not complex commands you need to run, so they're independent of the default shell you use.
If we put a #!/usr/bin/env bash at the start then they'll always run with bash regardless, even if you launch them with zsh/fish/other, which means that as long as you have bash installed somewhere (extremely common imo) it'll work.
That said, makefiles are very common and extremely stable and fairly convenient for most people I think. Let's see how it goes, and even if even need to migrate from Grunt at all - if we decide we do, and then we end up with quite a complicated script setup, make is definitely a reasonable option to clean that up.

Sorry I was MIA for a few days…

Where would you want to start? I think we could break this up into steps, and build the core library + drop old bits (old compat, persistence) + set up export/bundle formats (and test their compatibility) now, while thinking further about the plugin & dynamic config parts that need more design work separately.

I definitely don’t have time until probably late next week at the earliest, but I think what you’re suggesting more-or-less makes sense (excepting maybe dropping persistence, since I feel like the question is still open about what we do and don’t want, see below).
When you say “old compat,” do you have specific things in mind? Based on this discussion, I think the clearly droppable things are:

Lazy console definition, i.e. enableLoggingWhenConsoleArrives (still support funky environments with no console at all by just making all logs no-ops and never changing).
Anything we are current checking the IE user agent for, e.g. traceForIE.
Old syntax? (Easy to use let and some basics IE 11 supports, but I think class syntax might be good to use, too)

With that and separate ESM/UMD builds, we could start releasing v2.0.0-alpha.N builds tagged unstable on NPM and make continuous changes from there (with no compatibility guarantees from release to release).
Do you want to recreate a fresh v2 branch from the current main branch to target that PR to? While we’re talking branches, would you mind renaming the default branch to main?

Dynamic config

Accepting external changes from storage at runtime is significantly harder than external config at startup

Obviously I was not very clear! I just meant loading at startup (I probably should have said “runtime config” or “user config”). I agree live updating is much more complicated and not really necessary (or at least can be a plug-in). This is not a path I meant to send you down.

Allowing env/URL-based config is easier, but then brings back setDefaultLevel problem

What I meant here is that I think it might be OK to ignore this problem. IIRC I “invented” the concern that method was trying to address when I added it, and I am concerned I may have overinflated its value vs. the cognitive complexity it invites. (Another way to support this but that might be more clear is an initialization option, e.g. getLogger(name, { level: 'INFO' }). But maybe I’m overthinking it.)

we could allow runtime changes via an explicit a global API

Personally, I don’t think this shortcut really adds anything valuable over what’s already available.

More console methods

I think there are a lot of open questions here!

modern runtimes have generally standardized the console API, but would need investigation.

This is true, but a lot of these are stateful, and I think impose questions with non-obvious answers when it comes to multiple loggers.

@Ryuno-Ki I think @pimterry already covered what I would have said re: zsh/fish/etc. 🙂

When you say “old compat,” do you have specific things in mind? Based on this discussion, I think the clearly droppable things are: ...

Yes, I agree with all of those, the only other notable part to lose is bindMethod - we should be able to globally rely on Function.bind nowadays no problem. Given that we're moving to TS, we can actually use any modern syntax we like as it'll get automatically appropriately compiled away for the given target.

Do you want to recreate a fresh v2 branch from the current main branch to target that PR to? While we’re talking branches, would you mind renaming the default branch to main?

Both now done :+1:
Console APIs

This is true, but a lot of these are stateful, and I think impose questions with non-obvious answers when it comes to multiple loggers.

This is a good point! There's interesting solutions we could explore but yes multiple loggers do make it quite a bit more complicated. If there's any easy wins then we can consider including them, but happy to totally ignore anything non-trivial for v2.0.0.
Persistence
I think the runtime model is still interesting (controlling logs from debuggers/dev consoles is genuinely useful) but wouldn't be a breaking change to add later, so lets park that.
Changing the initialization logic later would be a breaking change though, so we need a plan for that up front.
For default levels, I do think there's a question here worth addressing... The problem is if the application developer (we can ignore libraries here I hope/assume) calls myLogger.setLevel('error') in their code to log only errors by default, and then runs it with an env var set asLOGLEVEL_MYLOGGER=info (probably not the actual env var format, we can bikeshed later). That doesn't seem especially unusual to me, what do you think?
In that scenario, presumably the intent is to override that error value to info instead. Given that, this means if an external input is set, we need to somehow ignore the setLevel call for the affected logger(s).
One option is that we just ignore all setLevel calls for the affected logger (but not other loggers, assuming we're going to use support some kind of logger-targeting syntax like DEBUG etc do). In effect, if you provide an external input, that forces the level of the given logger(s) indefinitely. Does that work? Seems like a reasonable & simple solution if the UX is OK.

OK, I filed a first step PR that drops special IE handling we no longer need in #203. It doesn’t try and change syntax, build tooling, module handling, or anything else yet. I’ll probably try and tackle separate ESM & UMD builds (and maybe TypeScript) next in a separate PR, since there are a lot more decisions and things to be done there.

Both now done 👍

Thanks!

if the application developer… calls myLogger.setLevel('error') in their code to log only errors by default, and then runs it with an env var set asLOGLEVEL_MYLOGGER=info… One option is that we just ignore all setLevel calls for the affected logger

That works, but then I feel like it makes setLevel() a little messy to reason about, and prevents you from opening the console and calling setLevel, so it doesn’t feel great to me.
What I was thinking with my last idea about getLogger(name, { level: 'INFO' }) was that would be the replacement for setDefaultLevel(). So an application developer would normally never call setLevel() (unless they setting up a UI or CLI option for users to set the level). Instead they’d set the default level when getting the logger:
// my-script.js
import { getLogger } from 'loglevel';

// Provide the default level as an option rather than getting the logger and calling `setDefaultLevel()`.
// No changes from today about how `setLevel()` behaves.
const myLogger = getLogger('myLogger', { level: 'error' });

// Rest of app code...
myLogger.info('Some info message');

And override at runtime as usual:
> LOGLEVEL_MYLOGGER=info node my-script.js

But, TBH, this whole conversation is making me feel like I’m overly worried about all this, and the current interplay between setLevel(), setDefaultLevel(), and reading persisted levels might be fine enough.


Vite/Vue: provide home page with minimal css

The Vite/Vue context should contain 2 apis:

one with empty home page, without CSS (what it is currently)
another one with minimal css (similar to what is generated by vite+vue)

The 1st one can be used for starting real project
The 2nd one is used for demo, as it's better to have minimal CSS than a simple text

For now, only the files responsibles for starting the project have been created, so we just need to generate them throught APIs right ?

yes, the new API with new methods will only generate another index.html file

Currently in process, soon available.


Self-contained dependency graph checker.

uses PackageVersionPubspec instead of PackageVersion, much faster Datastore responses (half the total time on my dev machine)
triggers the notifications internally via the callback function

The later enables us to decouple it from the package upload callback of the frontend, making it possible to move it out of frontend, and have it running in analyzer and dartdoc separately.

Okay, so we won't be triggering jobs from the post-upload handler anymore..., right?

Correct. I don't see it as a big issue, as the analysis may not start right away in either case.


BC, Canada, number in error

March 22-23, 2021, the number for BC was recorded as

“New confirmed cases by infection date
5033 (1612 – 21955)”

But instead of 5033 it should be 600 or so.

Thanks for opening this. Two points. 1. This is an estimate by date of infection and therefore in an increasing epidemic numbers will be higher than observed. 2. Looking at BC I see some reporting issues that like have driven some spurious results.


Parse float values

Hello! this makes it easier to parse for any chart data, what would you like changed?

I've added the requested changes and updated all the unit tests.  Best regards, Dylan

Hello, just wondering if you have any feedback? Thank you.

Thanks for the feedback -- updates have been made and unit tests are still all working.

within underscore, a ref to this doesn't exist for these originally changes them to native functions.

this was always undefined within the unit tests, if i didn't make the changes per request :D

Can we please get this approved, thanks man.

@dylansproule just published it as 1.4.0. Thanks for the contribution (and sorry for the delays).


middleman-deploy breaks the building and the server operations (on windows)

Hi!
Just by adding the line
gem "middleman-deploy"
in the Gemfile, the "bundle exec middleman build" command breaks down and the middleman server gives the browser a "File not font" error.
Gemfile:
source 'http://rubygems.org'
gem "middleman", "~>3.3.3"
gem "middleman-livereload", "~> 3.1.0"
gem "wdm", "~> 0.1.0", :platforms => [:mswin, :mingw]
gem "tzinfo-data", platforms: [:mswin, :mingw]
gem "slim"
gem "jquery-middleman"
gem "compass-rgbapng"
gem "bootstrap-sass", require: false
gem "middleman-favicon-maker"
gem "middleman-smusher"
gem "middleman-deploy"
The error at build is this:
C:\Sites\eg2016>bundle exec middleman build
C:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/pathname.rb:48:in []': no implicit conversion from nil to integer (TypeError)         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/pathname.rb:48:in chop_basename'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/pathname.rb:101:in cleanpath_aggressive'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/pathname.rb:89:in cleanpath'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/1.9.1/pathname.rb:451:in relative_path_from'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/lib/middleman-core/cli/build.rb:193:in execute!'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/lib/middleman-core/cli/build.rb:128:in invoke!'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/actions.rb:94:in action'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/lib/middleman-core/cli/build.rb:70:in build'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:27:in run'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in invoke_command'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor.rb:359:in dispatch'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/base.rb:440:in start'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/lib/middleman-core/cli.rb:72:in method_missing'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:29:in run'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/command.rb:126:in run'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/invocation.rb:126:in invoke_command'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor.rb:359:in dispatch'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/thor-0.19.1/lib/thor/base.rb:440:in start'         from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/lib/middleman-core/cli.rb:20:in start'
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/middleman-core-3.3.3/bin/middleman:18:in <top (required)>'         from C:/RailsInstaller/Ruby1.9.3/bin/middleman:23:in load'
from C:/RailsInstaller/Ruby1.9.3/bin/middleman:23:in `'
C:\Sites\eg2016>
And the middleman server gives this page, although it starts without errors and does not show any error when the browsers asks for the page
File Not Found/

Any update on this? It's driving me nuts running middleman server on a repo in a shared linux windows environment. Allthough I can confirm the "solution" from @KingwenChow works.

The above solution from @KingwenChow doesn't work for me. I thought it was a gem issue so cleared all my local gems then reinstalled sass, compass and bundler before re-running bundle install on my project.
Here's my gem file...

# Middleman modules
gem "middleman", "~> 3.3.3"
gem "middleman-blog", "~> 3.5.3"
gem "middleman-livereload", "~> 3.3.4"
gem "middleman-minify-html"
gem "middleman-smusher"
gem 'middleman-deploy', '~> 1.0'

gem "wdm", :platforms => [:mswin, :mingw]
gem "tzinfo-data", platforms: [:mswin, :mingw]
# gem 'win32-file'

# For blog posts using markdown syntax
gem "kramdown"

# For feed.xml.builder
gem "builder"


21 implement interaction with tx ack packet

Coverage increased (+0.3%) to 98.686% when pulling 1152f82f8d2594f22b5c4f6dca7a5ae717a4d456 on 21-implement-interaction-with-tx-ack-packet into 8df817767ef91800e07317f1aa51542ba807cf9e on dev.

Coverage increased (+0.3%) to 98.686% when pulling 9f4535cc7e2d360dc4b4cd7d830b58fa95e3bb8e on 21-implement-interaction-with-tx-ack-packet into 8df817767ef91800e07317f1aa51542ba807cf9e on dev.


How to access images as rosbag?

Hey,
How can we get camera images in the form of rosbag?

The images are not provided in the rosbag due to restrictions from the journal and space constraints and there is no plan to provide this.
The easiest method to create a rosbag would be to use the Docker Quickstart in the readme and record the rosbag with the images.


Repository structure (file layouts, cookiecutter templating engines, distribution options)

Starting this as a placeholder issue for tracking down tasks to be completed and those that are complete. I will be dividing these into separate issues and PRs
Cookiecutters

https://github.com/cookieninja-generator/cookieninja
https://github.com/cookiecutter/cookiecutter

as suggested by @Saransh-cpp
Examples

https://github.com/osl-incubator/scicookie
https://github.com/scientific-python/cookie
https://github.com/copier-org/copier
https://github.com/cruft/cruft/
Cookiecutter Data Science (drivendata.github.io)

Suggestions from @brosaplanella:

"A bit different, but Julia has DrWatson.jl which has many cool features, maybe we can get some ideas".
A figures folder (with a .gitkeep)
A data folder (later we could have some pipelines to process it, like the Data Science example above).

Possible layout
The folder structure can look like this
├── .github/workflows
├── src
├── data
└── docs
      ├── examples  # notebooks that can be rendered with nbsphinx
      ├── _static
      ├── sphinxext
      ├── source
      └── conf.py
├── tests  # (optional)
├── parameters
    └── my_parameters.py  # contains the get_parameter_values() function
├── examples/  # alternatively, example scripts or notebooks that are not to be rendered with the Sphinx builder
├── pyproject.toml
├── README.md
├── .pre-commit-config.yaml
├── .readthedocs.yaml
├── .env # contains DATA_PATH
├── noxfile.py  # (or tox.ini, if users want to use tox)

The required documentation should

Explain how to clone this template to start a new project
Explain how to rename the project in pyproject.toml and docs/conf.py
Explain how to structure a typical project with source files and utility classes and methods (in src/), unit tests with
Parameter entry points in pyproject.toml, with

[project.entry-points.pybamm_parameter_sets]
MyParameters = "package_name.parameters.my_parameters:get_parameter_values"

Point to the PyBaMM documentation wherein the developments and advancements in this repository shall be reflected on a separate page or section in the user guide

which can then be accessed as pybamm.ParameterValues(“MyParameters”) in the source code
Configuration options
Build-backends

hatch
flit
setuptools (later)

Documentation

Theme
Sphinx extensions

Project structure

Project metadata in pyproject.toml
and so on

Available licenses (#2)

MIT
Apache
BSD-3-Clause
and so on

So I am not sure how this will go yet, though I learned that cruft retains full compatibility with templates based on cookiecutter, but copier has some differences (it uses a YAML file instead of JSON for the project specification).
However, scientific-python/cookie supports all three of them, so I think our use case as a stripped-down, barebones version of it can also support all three—unless we don't need to support all three and just cookiecutter and cruft will be enough

Thanks for summarising this! Don't worry about supporting a lot of things at the start. We can start with a simple structure, one backend (hatch) support, and just cookiecutter support.

Rather than having a data folder, we should encourage separation of code and data with data path specified via the .env file. People are welcome to keep their code and data in the same place, but the data should ideally not be updated with the code to github, except for some examples.
If the data path is set as DATA_PATH="path/to/data" in .env, then the following code will load it
from dotenv import load_dotenv
load_dotenv()

path_to_data = os.environ["DATA_PATH"]

We could add that as one of the default utility functions in the src folder, e.g. in util.py
from dotenv import load_dotenv
load_dotenv()

def environ():
    return os.environ

What sorts of data would DATA_PATH contain ideally? We can further streamline the process of using it with some extra utility functions based on that too

Also, I renamed the project from pybamm-cookie-cutter to pybamm-cookiecutter because I saw that most templates with the cookiecutter topic on GitHub were named as such, i.e., without the space between "cookie" and "cutter"

What sorts of data would DATA_PATH contain ideally? We can further streamline the process of using it with some extra utility functions based on that too

Probably csv or parquet

I think csv and parquet files would be nice, we would have to use pandas as a dependency in that case (or just get it from the optional dependencies after https://github.com/pybamm-team/PyBaMM/pull/3144 is merged)
A utility function for them could be something like
from pybamm_cookiecutter.util import DataLoader
import pybamm

battery_data = DataLoader.load_data("file1.csv")

In other words, as a wrapper over a combination of load_dotenv and pandas.read_csv() with some customisation here and there

See also: https://learn.scientific-python.org/development/patterns/data-files/

Adding something else to this roadmap, it would be nice if we could add new models via entry points as well. This requires a few changes in PyBaMM though

The author would create a model class similar to pybamm's BasicDFN where it's entirely self-contained, then anyone else would be able to call the model with something like pybamm.lithium_ion.Model("author/model-name").
This would solve several existing pain points with adding new models:

PyBaMM’s submodel structure is too complex, huge barrier to entry
You have to add things to the PyBaMM repo, uncertain ownership and IP
PyBaMM team has to "endorse" every model or gatekeep

With entry points, adding a new model is separate from PyBaMM and authors get to retain ownership but we don't have to endorse the models

Ah, sounds great – a bootstrapped model should be possible to implement, and IIUC should work similar to how we do parameter sets; though I would like to note that parameter sets are returned as Python dictionaries so it's easier to handle them, here we might have to establish a class that can either parse the AST for a model (or rather just import a JSON-serialised model) to pass it to pybamm.lithium_ion.Model("author/model-name"). This might be better to do in the PyBaMM source code, as you mentioned.
This issue has been referenced in the GSoC 2024 ideas page for potential readers and contributors, so if and when we flesh out these ideas a bit more, I suggest we should edit and add everything to the top of the thread as well.

Rather than having a data folder, we should encourage separation of code and data with data path specified via the .env file. People are welcome to keep their code and data in the same place, but the data should ideally not be updated with the code to github, except for some examples.

I guess now with the pooch PR merged we could add the default pooch data files path for storing data here as well, which is under .cache for POSIX, and under %appdata% for windows machines. That way, we could use pybamm.DataLoader to load data files inside PyBaMM based projects.

Adding support for a data/ folder in the generated project, better guidelines on setting up documentation via MyST-NB (i.e., better ways presentation for results/code from research papers), etc., all sound like good feature sets for a v1 release someday, given that we are releasing v0.1 this week.


Operation request: Number parsing and Arithmetic operations

Summary
After filtering down a text to numbers, add arithmetic operations on the filtered results. to produce a single result output.
I often see textual stats from e. g. CLI output that I want to process a little further to get a mean or a sum.
Possible issues are handling of commutative and associative properties of subtraction division.
Example
Input:
Bananas: 50 pcs.
Apples: 5 pcs.
Oranges 2.5 pcs.
Recipe:
Regex(\d+(?:[.,]\d+)*)
New Feature: sum(lines)
or: mean(lines)
or: multiply(lines)
etc.
Example
Hope you find the Idea feasible for CyberChef.
Regards,
André

I would see this as a set of operations that perform arithmetic on the input. The delimiter can be set either as a newline, a comma, a tab etc. in much the same way as the Unique operation.
Some operation ideas:

Sum
Mean
Median
Product (or multiply)

We could even support more statistical functions like standard deviation.
If someone would like to have go at this, it shouldn't be too hard. Perhaps if you've been looking for something easy to get started on, this could be a good candidate. Feel free to ask for help and advice here or in the Gitter chat room: https://gitter.im/gchq/CyberChef

Closed in #215.
Example


Donor edits the pledge amount

[ ] Donor edits the pledge amount e.g. First pledged $7,500. Then wants to go back in and pledge a higher amount, say $10,000.

Workflow:

Donor goes to My pledges
Donor clicks on an aid package already pledged to
Donor sees Edit button
Once pledge amount is typed in, donor can click on Update button

@anupama-pathirage It seems there's no endpoint to get a pledge by donorID AND aidPackageID
Could you please check it?

Thanks @AmilaJ !

We need the following as well,

GET /{donorID}/aidpackages/{packageID}
We don't need this API because the page is public. It should be /aidpackages/{packageID} instead.
All aid package resources on the donor API should not send draft aid packages to the client.

btw, /{donorID}/aidpackages/{packageID}/pleges is sending an array. Since a donor can have one pledge per package, it should be an object, right?

btw, /{donorID}/aidpackages/{packageID}/pleges is sending an array. Since a donor can have one pledge per package, it should be an object, right?

Yeah, it should be, on the frontend I wrote the code to get the zeroth element on the array for now.


👨💻 Feature - React app Club Register Component

I want to have a Club's Register component for the react app

Guidelines ⚠
I have read the Contributing Guidelines 🔐
I have read the Setup guidelines 🔐

Notice ⛔
Please make sure in the .css files you are making/using , the styles should be applied to Unique Class names
If there are images in your .jsx files  give them unique classnames like registrationImage , clubLoginImage, then in the css files make sure the styles are applied to those unique classnames. Else things are getting messed up.

FIXES 🛠
If you look at the registration page for the USER , it looks like this ⤵

I want to have this same page for the CLUBS to register
🧵 Data --> Club Name , Club Email , Password , Adress , Pincode
Here are the files ClubRegister.jsx and ClubRegister.css ⤵

To-Do 🗒

You can copy the code from UserRegister.jsx
In `ClubRegister.jsx you can have this image --> Signup Image
Make sure the styles, colors, fonts of  ClubRegister.jsx is similar to UserRegister.jsx  except for the image

Completed / Doubts ?  🚀
Once you are done with the code , please tag me in #milan with the Screenshot of whatever you made so that we can review that there together.
If you have any doubts, queries please tag me in #milan so that we can discuss the issue there together.
Please Donot DM.
Cheers 🥂

I want to work on this issue under JWOC

Assigned to you , @KushalGhosh9899


[WIP] Improve header structure

Move top links out of page sections

Add chapters to document outline

Clean up header structure by removing non-essential headers from
widgets.

REDMINE-16511

Coverage remained the same at 99.286% when pulling 16a82d3e55c7146efda981f256218b414f26db0d on tf:document-outline into 1f8c55e786f323b8afc8e52137bc56783dace3b7 on codevise:master.

Coverage remained the same at 99.286% when pulling 16a82d3e55c7146efda981f256218b414f26db0d on tf:document-outline into 1f8c55e786f323b8afc8e52137bc56783dace3b7 on codevise:master.


[Bug] Faucet giving 500 error during the mint command

🐛 Bug
Trying to follow the 'My First Transaction' tutorial and its failing to provide me with coins from the faucet as its giving me a 500 Internal server error.
To reproduce
Code snippet to reproduce
git clone https://github.com/libra/libra.git && cd libra
git checkout testnet
./scripts/dev_setup.sh
./scripts/cli/start_cli_testnet.sh
libra% account create
libra% account create
libra% account mint 0 110 LBR

Stack trace/error message
libra% account mint 0 110 LBR
>> Sending coins from faucet
[ERROR] Error transferring coins from faucet: Failed to query remote faucet server[status=500]:
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2 Final//EN\">\n<title>500 Internal Server Error</title>\n

Internal Server Error
\n
The server encountered an internal error and was unable to
complete your request. Either the server is overloaded or there is an error in the application.
\n"

Expected Behavior
It should successfully mint me some LBR tokens from the faucet.
System information
Please complete the following information:

testnet branch. Commit: 4d1a383caaa03ae0e80596000e0444a161d81941
Rust version: Unknown
Mac OS X High Sierra 10.13.6

So it worked when I tried it again but only once now I'm back with the 500 error. Is the faucet being DoSed?

if it persists, feel free to re-open.


Adding "string-name" as a possible contrib name entity in JATS parser

At least some JATS (PNAS, notably) may use a <"string-name"> tag for a contributor in place of <"name">.  The included test file includes an interesting side case where there are a large number of otherContribs.

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.22 :tada:

Comparison is base (b1b1890) 86.62% compared to head (0fe842b) 86.85%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main      #39      +/-   ##
==========================================
+ Coverage   86.62%   86.85%   +0.22%
==========================================
  Files          20       20
  Lines        2094     2099       +5
==========================================
+ Hits         1814     1823       +9
+ Misses        280      276       -4

Impacted Files
Coverage Δ

adsingestp/parsers/base.py
93.18% <ø> (ø)

tests/test_arxiv.py
94.73% <ø> (ø)

tests/test_crossref.py
93.93% <ø> (ø)

tests/test_datacite.py
90.90% <ø> (ø)

tests/test_elsevier.py
90.90% <ø> (ø)

tests/test_jats.py
93.93% <ø> (ø)

tests/test_wiley.py
91.17% <ø> (ø)

adsingestp/parsers/datacite.py
89.08% <100.00%> (+0.64%)
:arrow_up:

adsingestp/parsers/jats.py
86.79% <100.00%> (+0.58%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Tool falls into uninterruptable sleep when it's closed with a running app

Godot version:
d486cae7016c77af114d8019abf37c57e8bba386
OS/device including version:

linux
Issue description:
E.g.: start the godot tool in a project folder with godot -e and play (f5) the project.
Close the tool window.
The terminal is blocked, godot runs forever (sure, until you press the power button):
ps -aux | grep godot
username       10403  1.1  0.0      0     0 pts/23   D+   21:24   0:23 [godot3]

killall -9 godot3

ps -aux | grep godot
username       10403  1.1  0.0      0     0 pts/23   D+   21:24   0:23 [godot3]

and prevents the computer from going to suspend (stand-by) mode
Jan 12 07:41:14 t2t systemd-sleep[31371]: Suspending system...
Jan 12 07:41:34 t2t kernel: [47564.481329] PM: Syncing filesystems ... done.
Jan 12 07:41:34 t2t kernel: [47564.528695] PM: Preparing system for sleep (mem)
Jan 12 07:41:34 t2t kernel: [47564.528936] Freezing user space processes ...
Jan 12 07:41:34 t2t kernel: [47584.532861] Freezing of tasks failed after 20.004 seconds
(3 tasks refusing to freeze, wq_busy=0):
…
Jan 12 07:41:34 t2t kernel: [47584.533187] godot3 D    0 23897   2930 0x00000006

I can't reproduce this any more, it was probably a kernel driver issue.


fallback to classname when LM doesnt have config

A fix for https://github.com/EleutherAI/lm-evaluation-harness/issues/1333

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for the PR!